Hi, Am Freitag 13 April 2012, um 11:54:51 schrieb David Woodhouse: > On Tue, 2012-04-10 at 21:51 +0200, Patrick Ohly wrote: > > On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: > > > Which is the long-term vision for Evolution in this regard? > > > > Lack of proper offline support has been my main motivation for > > developing SyncEvolution. I know from others that they, too, would love > > to see this supported natively in EDS+Evolution, without the need for an > > external application. > > > > If there is sufficient interest, then I would be open for discussions > > about how SyncEvolution could be integrated seamlessly into Evolution. > > This would bring offline support for CalDAV, CardDAV, ActiveSync and > > might even add support for SyncML peers (client or server). > > I think this could be a really interesting way forward. > > The protocol-specific back ends in Evolution all lack proper > synchronisation support. Their offline operation is read-only, or if > there's offline write support then its capacity for reconciling changes > when it syncs up with the server is very limited. > > We'd definitely want to offer a generic capability within Evolution, for > the various back ends to use to support an offline-writeable mode and > resolve conflicts correctly. Exactly how to detect a sync conflict, and how to act upon one, once detected, is highly specific to the groupware server you talk to. I do not believe a truly generic approach which fits all kinds of groupware servers could ever be finished. ;-) Having a generic mechanism around for dealing with the common aspects of synchronization, however, would do much good. Without having seen SyncEvolution's code base, I guess there are common parts as well as server/protocol specific parts - the latter of which would need to be implemented by the backends, while the common parts (including a mechanism to ask for user interaction while syncing) would need to be implemented only once. But, you may want to bear in mind, that the choices you have in resolving conflicts are dependent on the server you talk to as well. > So, why *not* use SyncEvolution for that, since it can already do it and > it's a *lot* of work to get it right if we were to reimplement it all? Should be fine for the protocols SyncEvolution already supports, at least. > Imagine we ditch Evolution's protocol-specific back ends, and replace > them with something which is basically a local file back end and uses > SyncEvolution (or a derivative/subset of it) to actually communicate > with the server. The different groupware servers do follow their very own paths in how they want to be dealt with. The backends, as I see them now, are mere protocol implementations (or transformers), with offline capabilities attached to them (or not). The groupware server protocols need to be implemented somewhere... not sure whether you could really replace the backends as they are now. Turning SyncEvolution into a common infrastructure which can be used by the backends seems like a more straightforward way to me. > Obviously you'd want changes to be made directly when you're online, "Online" in the sense of "service can be connected to" or "online" as in "client state"? :-) > so > that errors like 'storage full' would be shown immediately. And you'd > want to propagate the storage restrictions (only one mobile number in a > vCard, no ThisAndPrior recurrence exceptions, etc.) to the capabilities > of the particular store. And one or two other details, but I think as a > whole it could work out extremely well. > > I really wouldn't want to see us reinventing the wheel and trying to do > full sync and conflict resolution in Evolution — not in a generic way > for all Evo back ends to use, and *especially* not over and over again That would be very nice, indeed. Still, I have doubts whether you can have a fully generic way of dealing with that, without being forced to make compromises which make it impossible for certain backends to support their respective server capabilities in full. Still meditating on that... Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.