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

[Milan Crha <mcrha redhat com>]

On Tue, 2012-04-03 at 13:33 -0400, Matthew Barnes wrote:
> On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote:
> > Just rough thinking, nothing elaborate as yet - I'll be meditating
> > this. :)
> 
> Rough thinking here too.  I'll let it simmer.

	Hi,
this thread is getting quite complicated, and I confess I'm rather lost
here (the final outcome should be clear, right). But to summarize which
things are discussed here a bit (or better those I understood):

a) Add an explicit method to synchronize local changes into the server
b) Add some mechanism to ask user for conflict resolution during a)
c) Tell backend to work in "offline mode" - do no network operations
d) Notify client about current "offline mode" being used by the backend

--------------------------------------------------------------------------

ad a) There is agreed about the method addition, and I agree too. Maybe
a different method prototype would be used (more parameters, see below).
I suppose, you still tries to write the changes to the server as soon as
possible, when in online mode, right? It makes sense, I'm only checking.

--------------------------------------------------------------------------

ad b) This is quite complicated, the backend cannot rely on gtk+,
because it would bring the dependency on the factory and the factory may
not depend on the gtk+, it should be runnable without live desktop, only
from a terminal. Correct me if I'm wrong. The idea of "another process
taking care of the user interaction" is, apart of quite complicated,
also not easy to do, what if you run the server without live desktop, or
if you run on thin clients, or ... I'm afraid there can be many ways how
to break this approach. Thus, what about adding a DBus signal on the
backend for conflict resolution, something like:
   void resolve_sync_conflict (
		guint sync_op_id,
		const gchar *server_object,
		const gchar *local_object);
which backend will throw and the client side should response through
something like this method:
   void sync_conflict_resolved (
		guint sync_op_id,
		ESyncConflictResolution resolution);
where ESyncConflictResolution will contain values like:
	Unknown
	ServerWins
	LocalWins
	... (maybe more, Christian may advise better)
Of course, the client part should implement this, which is basically
undoable for all of them (and some even do not use gtk or any user
interaction at all), thus I would add one parameter to the "synchronize"
method, the ESyncConflictResolution value, which will pick the desired
strategy. If it is "Unknown", then the backend can use the signal and
wait for the method to resolve conflicts (better name from "Unknown"
would be "Ask"). Of course, clients without user interface will not call
the "synchronize" method, most likely.

The resolve_sync_conflict() uses strings for objects, and based on the
EClient type it's either ECalComponent or EVCard as string.

--------------------------------------------------------------------------

ad c) The mailer part does this in global, not per-account bases. Maybe
the client may have this done in the same way. Nonetheless, in a
multi-client environment you may make sure that the clients will not
fight on this (when one requests backend to stay offline while the other
will require it to run in online). Note the factory uses the same
backend for each client it connects to it, that's why they can fight.
The current "online" property works fine for me for these purposes, but
if you really want, then rename it. Still, this should be, from my point
of view, just a preference given by the client (user) whether the
backend should or should not do any network operations. You've right
that there should be distinguishable whether the offline state was
initiated by a user, or by connection issues (wifi disconnected, vpn
dropped and so on), thus the backend can decide whether the connection
it has currently opened with the server is still alive and it can close
it properly - otherwise it would just timeout, and these timeouts aren't
short. New network-related property comes in mind.

--------------------------------------------------------------------------

ad d) For cases like "network unavailable" or "the network available,
but the destination server unreachable" the backend can notify clients
about its online mode. (There is a "special" case when you connect to
the server for the first time, thus the backend may report an error,
rather than running in offline mode against the server address which is
not reachable, because of typo in its URL.) There is currently a
mechanism to notify about onlinity by the backend towards its clients,
the only thing is that evolution itself doesn't indicate it in any way
to the user in its UI. For example CalDAV calendars can run online, and
after it realizes the server is offline, they switch itself to offline
mode (it doesn't have any offline mode implemented, it just prevents it
from doing event changes - by setting itself to readonly mode too), and
if it realizes later that the server is reachable again, then it
connects to it and continues online. I do not think the network monitor
would help here anyhow, the backend will only know for sure when it
tries to connect. From my point of view, this property should be used
only for indications on the client side, not to guess from it what
backend can do and what not when its offline. There is also a "readonly"
property, which serves for related purposes.

--------------------------------------------------------------------------

One more thing, which I didn't get is, what to do when you connect to
the server and you have objects in your offline cache to be uploaded to
the server. Christian said they are not trying to upload them, but it
may also not try to get changes from the server, because that's the
point where the conflicts happen, say when server has modified the same
event I modified in offline. Still, you want to get changes from the
server right after connected to it, to show new events to the user, but
you cannot synchronize? I would say it's unexpected by most of the users
(there is opened a bug report where reporter claims that the backend
updates its changes too often, when he has there set a refresh for one
day (I do not recall the exact interval value), but the backend updates
with server changes right after being opened, which is unexpected for
him - I guess it's rather rare case).

OK, I made this slightly longer and I'm sorry if I wrote anything
obvious up there (which I surely did). In that case just consider this
as a little summary for this thread.
	Bye,
	Milan