Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

[Milan Crha <mcrha redhat com>]

> On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: 
> First of all, no, the things discussed here are not going to be
> easy, and it raises the question what Evolution actually wants
> to be. Does it want to be a fully offline-capable PIM/groupware
> client? That means, does it want to support backends which are or
> strive to be?

	Hi,
there seems to be a minimum work to be done on evolution's side, the
most work will be done on eds part, in respective backends. From what I
understand you want the "Synchronize" button for evolution. That should
be pretty easy, add clients there based on some capability, with similar
functionality like the Send/Receive button in mailer.

> Which is the long-term vision for Evolution in this regard?

We (I'm sorry for the plural) definitely want to be the best, of course :)

> I guess finding a good balance here is difficult. Supplying the user with
> a dedicated sync button is a good thing, and should be done, but you're right,
> bugreports will come from users who forgot to press the button. A refresh
> timeout with a sensible preset seems to be a good thing, too. Maybe it would
> be worth it that the refresh can simply be disabled without changing the preset,
> that would help users who go on travel and who know that they'll be on shaky
> lines for the next week (is it that way already? /me needs to check).

calendar/book can provide a Refresh interval option, most remote do
that. That's what you call "preset", I suppose. You cannot force "no
checking when I'm on this network" currently.

> 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.
	Bye,
	Milan