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. 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? 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. Obviously you'd want changes to be made directly when you're online, 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 in the different back ends for their own purposes. -- David Woodhouse Open Source Technology Centre David Woodhouse intel com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature