Hi Matt,
thanks a lot for picking up this topic, as it is quite essential for us.
Maybe others can join in as well in order to iron out what would be needed
here.
Am Dienstag 03 April 2012, um 14:14:52 schrieb Matthew Barnes:
> On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote:
> > Next part is, that I think network (un)availability and Evolution/E-D-S
> > online/offline state are two separate things, which got mixed in the
> > current implementation. Network unavailability means I cannot write my
> > objects onto the server. In evolution-kolab, whenever a PIM object is
> > saved, it is first stored in the local write cache. If in "online"
> > state (as in Evo 2.30 semantics), evo-kolab would then try to push the
> > object onto the server, which may fail due to a multitude of reasons -
> > server down, network line shaky (connection dropouts),
> > firewall-of-the-day is active or whatsoever. The PIM object then simply
> > stays in the offline cache, waiting for a later successful sync with
> > the server.
>
> Still not sure how synchronization should be triggered in the UI, but I
> like the idea of a synchronize() method for EClient. I think being able
> to explicitly say "synchronize my changes now" is an important use case
> that we're lacking at the moment.
Apart from being rather simple as far as the implementation goes, as I tried
to outline in my lengthy posting, there is also a psychological aspect to
a dedicated synchronization event triggered by the user:
* no surprise if things take time and CPU/network gets hogged, since
the operation was explicitly requested by the user
* no surprise if sync conflict dialogs pop up
* no guessing needed by the backends as to when to trigger a sync
run, cals/books stay responsive, no need for possibly quirky workarounds
> Conflict resolution is a tricky case that to my knowledge we've not
> really dealt with before.
In evolution-kolab, we do. We have to, since shared cals/books are
common use case (even more common than personal, non-shared ones).
We therefore examine our IMAPX cache (all PIM objects are stored as
emails in Kolab world) - this is "the server state as it was before".
Next, we have our write cache, which - after offline store operations,
like creating new objects and changing existing ones - may contain
potentially conflicting local changes, and finally the server side,
which may contain potentially conflicting remote changes.
> I don't think a UI for conflict resolution
> necessarily has to be programmed into Evolution. In fact I'd prefer it
> isn't since it would leave other E-D-S clients out in the cold. Instead
> the backend itself could spawn off some specialized GTK+ process that
> pops up a conflict resolution window. Then we wouldn't have to worry
> about stuffing conflict resolution methods into the client-facing APIs.
> It would be automatic as far as E-D-S clients are concerned.
As it is the backend which needs to deal with the conflict resolution,
and since it is the backend which needs to actually acquire the user
input regarding how to act on the conflict at hand, leaving out Evolution
from all this seems to be a good way to do it. I could imagine some
service process for this, which backends can use to request user input,
in order not to make Evo special among the E-D-S clients. Once the conflict
is resolved, the backend can notify interested clients about the change,
that's it.
Let me once again underline that the current implementation in evolution-kolab
with the sync conflict resolution strategy preconfigured per folder
(take newer object, take server object, take local object, create duplicate)
is a result from the lack of exactly this infrastructure, that a backend
cannot request user input in a generalized manner. In real life, these preconfigured
resolution strategies will fail to accomodate for what the user really needs
(which is a from-case-to-case UI dialog). It is just a mere workaround.
> As for Evolution's forced offline mode feature: at present it only
> applies to mail since mail is still in Evolution's exclusive domain.
> Once mail joins address books and calendars as a desktop-wide service
> with potentially multiple apps acting as clients, I plan to remove
> Evolution's forced offline mode entirely since it won't be applicable
> anymore. This is part of my campaign for one E-D-S client to not get
> special privileges over other E-D-S clients. We need to forget about
> the 'E' in E-D-S.
Make that 'E' an 'Extensible' or 'Elaborate' or whatever, and it will
fit again. ;-)
> That said, EBackend's online detection is too simplistic at present.
> I'd like to make each EBackend determine its own online/offline state by
> way of g_network_monitor_can_reach(), but I'm holding off on that until
> my account-mgmt branch is merged, so EBackend will have a consistent way
> of getting the server address to feed to GNetworkMonitor. Still, seems
> doable by 3.6.
Well okay, that's a little more than the current EBackend "online" property,
since it can tell me whether a certain host can be reached. But, AFAIK, it
can not tell me whether a given service on that host can be reached (that
is, can be connected to), right?
In the present evolution-kolab implementation, there is no check whether
the network is actually on or off, it is the online/offline state (previously
set by the user) whether the backend tries to push the changes to the server
or not - in case of failure, the object stays in the offline cache.
What I meant to say in my post is that it would be a good thing to add
some mechanism through which the user can request the backends to go into
offline state, even if networking is available. The fact that Evo should not
be a privileged E-D-S client makes that difficult to implement, however,
since not all backends may implement full offline capability, and other
E-D-S clients would need to be able to switch that state as well... I guess
evolution-kolab would be able to live with a dedicated synchronize() operation
and an offline operational mode which is triggered by network availability
(though, IMHO, a dedicated online/offline state switching would provide a
smoother, well, "user experience").
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.