Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Tue, 2012-04-03 at 12:05 -0400, Matthew Barnes wrote: On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote: Seems to me that opening a connection in order to find out whether I could open a connection is more than evo-kolab would need. Unless the service-available check would be really cheap, it seems to me that host-reachable would suffice. Once I actually try to connect and fail, I know that I cannot connect. Nothing lost. ;-) (What's more, if service-available was TRUE half an hour ago, when the check was made, that does not automatically mean that it is still TRUE when I want to actually *use* the connection half an hour later - so, not sure whether a service-available check would help much). Perhaps then simply rename the online property to host-reachable to clarify it's meaning as a first step? Online seems like too nebulous a term in this context anyway. Note that in the case of something like a company EWS connection, when the user does something in Evolution that triggers that account to go online, you'd actually want it to trigger a VPN connection so that it *can* reach the host in question... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi, Am Mittwoch 04 April 2012, um 15:09:36 schrieb Milan Crha: On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: [...] As for evolution-kolab, sadly, there is no good way to do a quick check for changes, at least I do not have an idea how one could implement one, since the server does not do any kind of bookkeeping for the clients. One can check IMAP UIDs, any change on them in a PIM folder indicates that a sync is needed, but you do have to search for the changed objects then. It could slow down the open() operation for a cal or book dramatically if the sync was done there, that's why I did not put a sync point there for evo-kolab (though it could easily be done, but it may create the impression that the cal/book itself hangs... and is opening the cal/book cancellable? I don't think so). Yes, the whole opening phase is cancellable, and is fully asynchronous (signal-driven), thus the client says open me, and it receives confirmation your request begun as operation X, then it is waiting for a confirmation for I'm (not) opened now, which can come anytime. Authenticating against the server (asking for a password) is part of the opening phase. This is there since EClient, thus not for a long time. You've right having it part of the open itself is too much, that's why current builtin backends initiate a delta thread, which takes care of regular updates (based on the 'refresh' interval) and also possible upload of changes. Because it runs in its own thread, then there is no slowdown during the opening phase. Of course, current builtin backends do not use real offline handling, as far as I know. That's the subject to change. This approach can be done in async backends, for sync backends it is harder to do. Some behaviour I see in the sync backend classes, to me, creates the impression that sync backends are being phased out and the async ones are the preferred ones. It is true that the async approach has its beauty, but e.g. evolution-kolab is not yet there. It would need to remain a sync backend for some time, there still is internal stuff to be straightened out (I'm trying to do that presently), and evolution-kolab be changed to async only after that (fixing the existing bugs first, then introducing the new ones ;-). Especially for offline-capable backends, the open() operation could return really quickly (using the local cache). Imagine you open() a backend mistakenly (you wanted the other one, really), and the one you mistakenly opened starts its syncing run. Maybe not so nice. Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
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/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
