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