On Sat, 2010-08-21 at 08:43 +0100, Sateesh Kavuri wrote: > >>>> [SK] This agreement is something that would be part of the protocol in > >>>> use. Apparently SyncML does not have this facility. > >>>> > >> It does. uri=calendar/work and uri=calendar/personal can be used. The > >> only problem is that most existing services do not offer that. > >> > > In my limited experience, most services seem to allow the URI to be > > specified > > (not least because of the different values expected by different devices). > > It isn't clear to me how the URI the remote side specifies in the SyncML > > request interacts with the URI values in the service profiles (or, more > > importantly, the values in the user's own sync profiles). Can you explain a > > bit more how the LocalURI and RemoteURI are used? > > > The RemoteURI is used to identify a database on the remote service, so a > service XML would have this information whenever the device in question > would like to initiate sync with the target service. Similarly, a > LocalURI is published > to be used by other services when they would like to synchronize with > the host device
So the LocalURI really only applies to SyncML, but not the local data, right? How is the local calendar selected? I assume this is in the user's sync profile. This is specific to the storage plugin referenced in the service profile. So a GUI which wants to configure that part of the sync profile needs to know which databases are supported by each storage plugin and which keys to set in the per-storage part of the sync profile. It cannot get this information from Buteo at runtime, so in that sense a GUI is always written for a specific set of plugins which may appear in the service profiles, right? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
