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/
Attachment:
signature.asc
Description: This is a digitally signed message part.