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

Hi there,

Am Mittwoch 04 April 2012, um 19:11:46 schrieb Matthew Barnes:
> On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote:
> > How about the "service-available" to be set much like the to-be
> > "network-available", through GNetworkMonitor, as an EBackend property,
> > which, when changed, emits a signal?
> > 
> > Just rough thinking, nothing elaborate as yet - I'll be meditating
> > this. :)
> We discussed this briefly on IRC, but just to follow up more formally.
> Having stewed on this overnight I think we're coming at the problem
> wrong.  The question boils down to "can the backend operate on its data
> set or not?"  That status is as much as we need to expose to clients, I
> think.  Network availability and remote server availability factor into
> the answer but clients need not care.  If a backend is offline-capable,
> then the answer -- as far as the client is concerned -- is always "yes".

This is pretty much how evolution-kolab behaves. From a technical point of
view, if the (E)Client knows the backend in question can operate on the
given data set, that is simple, sound, and enough for the client to know.

What comes to mind is the non-technical, more user-oriented view.

Say, a group of users share a common calendar, which, as I outlined before,
is a much common use case for Kolab (more common even than private ones),
and I guess it is the use case a "groupware" server is all about.

Now, if a user edits and saves an event, and my backend says "yes, I can
operate on the data" -- what is it the user expects? What she will *see*
is, with the above model, that the newly created or changed event got saved.
If she is not keenly watching her networking status, she will assume that
the event got stored on the server, visible for the others in the group.
If the backend, instead, finds, it cannot reach the server, the event will
be stored locally and not be visible on the server. The user will proceed
with her daily work, assuming the new or changed event is visible to the
others in the group, while, actually, it is not.

If the backend has no notion of a dedicated "offline" state, and such is not
visible in Evolution or any other client, how does the backend tell whether to
report an error that the object could not be stored on the server and has been
saved locally only, awaiting synchronization? For the backend to be on the safe
side, this error would always need to be reported.

Say, the user has purposefully disconnected from the network. She will then
know that the objects cannot be stored on the server. And she will also know
that, once she reconnects, she will need to trigger a synchronization run.
On the other hand, while being disconnected (e.g. for a couple of hours or
even a few days), she will find it much annoying to be told each time she
stores an object that it could not be stored onto the server - "Yes, I know
it cannot be stored, as I AM OFFLINE!".

This is why I propose a dedicated offline state, which is not dependent on
network availability, and which is visible to the user by being displayed
in each client that connects to E-D-S. Such a state makes it very clear to
both, user and backends, how to act and what to expect during the workflow
(for instance, there cannot be any sync conflicts while working in offline
mode - the user just plainly does not expect to see any in this case).
It also seems that online or offline is not a state the E-D-S clients need
to maintain, but it is rather a status E-D-S itself maintains (and tells it
to its backends as well as to any client that connects and has the capability
to display E-D-S's current status). Once a client requests E-D-S to change
online/offline operational mode, the change request can be propagated to
both, all backends which do implement a notion of online/offline operational
mode, as well as to any client connected to E-D-S which has the capability
of showing E-D-S state.

Kind regards,


kernel concepts GmbH       Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]