please stop mail sending me.
On 8/19/10, Graham Cobb <[email protected]> wrote: > On Thursday 19 August 2010 13:09:02 [email protected] wrote: >> > -----Original Message----- >> > From: ext Yves-Alexis Perez [mailto:[email protected]] >> > Sent: 19 August, 2010 17:15 >> > >> > Emphasis on *at a time*. And by the way it's not possible to do that at >> > the moment to do that, everything as to be in the same calendar if you >> > ever want to sync it somewhere. >> > >> > When using sync with the device as a “server” (meaning, another, non >> > MeeGo device, requests the sync), it should ask for which >> > calendar/contact/task/... it wants specifically. >> >> [SK] This is infact possible in N900. There is a pop-up dialog box that >> asks the user to choose the dialog and this choice very much depends on >> the kind of concept we define for MeeGo (for which the UI spec. is not >> yet defined) > > It feels like this is being implemented without any clear requirements being > specified -- is there a requirements spec that can be published? > > Sync is a horribly complex area (as those of us who have worked on OpenSync > on > and off for many years know only too well!). And different users have > different requirements. > > I am wondering whether my use cases are being allowed for -- it is hard to > work out from what has been said so far. Let me try to describe them (note > the usage of "client" and "server" in SyncML can get quite confusing -- to > try to reduce confusion, I will use "device" for the typical role of a > handset and "master" for something like google or exchange). > > 1) I have multiple calendars on my device (say work, personal, children). > > 2) Each calendar synchronises (as a "device") with a different "master" (say > MS Exchange for work, google for personal, etc). Some of these are SyncML > interfaces, others may be applications directly on the device (e.g. MfE), > others may use protocols which I, as a developer, want to add. > > 3) Each calendar can synchronise (as a "device") with multiple "masters" > (personal calendar synchronises with google and also synchronises with > kontact on my desktop). This is very often used as a "poor man's" way to > sync two applications which won't sync directly! > > 4) Each calendar can synchronise as a "master" (not a device) with > other "devices" (e.g. other phones or a kitchen clock or something). This > is > particularly important for netbook mode but it should also be available on > handsets. > > 5) External masters must be able to initiate syncs with various calendars on > the device without any user intervention (with approriate access > credentials, > user approvals, and calendar names). So, for example, my desktop might > synchronise automatically every night if I have my device plugged in, or > might synchronise automatically as soon as it sees me come within bluetooth > range. > > 6) It should be possible to schedule syncs (the scheduling is a system > issue, > not a Buteo issue) to be initiated by the device, without user intervention, > to various masters (for example, my personal calendar might sync with Google > at 23:00 every day and my work calednar with MfE at 08:00 every day). > > 7) It should be possible for the user to initiate a sync where the MeeGo > system acts as a "master" for another device, and it should be possible for > external devices to initiate syncs with the MeeGo system acting as a master. > > 8) Everything I have said about calendar applies to contacts and other PIM > items in the same way. > > These use cases are real. With the exception of the "acting as a master", I > use these with GPE on my Maemo device today (but not using SyncML). The > master mode does not currently work just because I have not maintained my > port of OpenSync to Maemo but I did use it in the past. > >> >> > When using sync with the device as the “client” (for another device or >> > to http servers or something) then when configuring that agreement on >> > the device, one would chose which calendar/contacts/tasks/.. to be part >> > of that agreement. >> >> [SK] This agreement is something that would be part of the protocol in >> use. >> Apparently SyncML does not have this facility. One way is to define an >> extension to SyncML and hope that the target also supports it (Google >> anyway uses REST for Calendar sync, so this is out of question) > > Hmm. Patrick knows much more about SyncML than I do but I thought there was > a "database name" in SyncML. I would expect the database name to be > something like "calendar/work" or "calendar/personal" (with just "calendar" > being a valid name for a default calendar). For Google I would assume that > different URLs would be used for different calendars. > >> > Not sure if I use “client”/“server” correctly, feel free to point me to >> > the correct terms. > > My understanding of the SyncML terms is that they are the other way around. > But I may be wrong. That is why I avoided using "client" and "server" > above! > > Graham > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
