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

[Matthew Barnes <mbarnes redhat com>]

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.

Conflict resolution is a tricky case that to my knowledge we've not
really dealt with before.  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 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.

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.

Matt