Hi everyone, being back in the office and having cleaned up my desk, let's heat up this topic again, so it hopefully will get us somewhere. Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg: > Hi everyone. > [...] > Back in version 2.30, Evolution has not had a dedicated "synchronize" > button, but there has been the online/offline button, which, when toggled, > resulted in a synchronize() function being called in the cal/book backends. > [...] > In version 3.4 of Evolution, this functionality is no longer existing. Backends other than evolution-kolab may not miss that right now, since (IIRC) none of them implements offline write operations, but all go into read-only mode when offline (please correct me if I'm mistaken). evolution-kolab does miss that, since it already implements full offline write support, which was working in 2.30, but now, the existing functionality cannot be used as before. The following is involved: * CamelIMAPX inside KolabMailImapClient (implements the read-only disk cache for us) * KolabMailSideCache (implements an offline write cache which holds locally changed objects in offline mode and acts as a write-through cache in online mode for PIM objects) * KolabMailSynchronizer (implements collision detection and resolution for PIM objects, used when changing online state as well as in online mode) Unless there is a dedicated synchronize() function with which we can tell the backend to do the synchronization, most of this already-existing infrastructure is not usable in evolution-kolab, but is sitting idle. It has already been agreed upon (see previous posts in this thread) that such a synchronize() function is needed and that it can be triggered from the EClients in a sensible way. Question is, how and when will it be implemented so we can test the migrated evolution-kolab parts waiting for that. Moreover, there's a GSoC project (see https://live.gnome.org/SummerOfCode2012/Ideas) for a backend cache infrastructure (the Ideas page still outlines a Contact cache - is this up-to-date?). Via KolabMailSideCache and KolabMailInfoDb, evolution-kolab already implements an offline cache for both, contacts and calendar types. Albeit being somewhat Kolab-centric at present, this is a working offline cache infrastructure already existing, which could be generalized and/or cannibalized for a new cache usable by all backends (including evolution-kolab). I'd be happy to use a generalized backend cache in evolution-kolab, rather than having each backend implement its own cache, provided evolution-kolab's needs (like being able to store binary blobs) are satisfied. Feel free to ask questions - I'm here to answer them as much as I can. 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.