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". Here's the set of properties I propose for EBackend to replace the current overly simplistic "online" flag: "host-reachable" type: boolean perm: read-only default: false EBackend itself updates this as a convenience for subclasses, but this status need not be exposed to client applications. For network-based backends, this property is the result of running g_network_monitor_can_reach() on startup and in response to changing network conditions or when the "socket-connectable" property changes. For local-file backends, the host is assumed to be "localhost" which is always reachable. So the property will always be TRUE for them. "socket-connectable" type: GSocketConnectable perm: read-write default: (see below) This is the GSocketConnectable fed to g_network_monitor_can_reach(). EBackend itself will initialize this to a GNetworkAddress based on the host and port settings in the ESource. Subclasses do have the option of overriding this, however, which is why it's read-write. If the pointer is NULL, this is assumed to mean "localhost". Setting this property will trigger a "host-reachable" notification after EBackend runs g_network_monitor_can_reach() on the new value. This property could prove to have additional uses in the future as we further embrace GIO's networking APIs. "readable" type: boolean perm: read-write default: false This property is exposed to clients. It indicates the backend's data is viewable but not necessarily complete, as in the case of a network outage and not having fully synchronized for offline usage. Backends are responsible for updating this themselves. Clients are responsible for disabling the relevant UI elements when this property is FALSE. "writable" type: boolean perm: read-write default: false This property is exposed to clients. It indicates the backend's data can be modified, but possibly only locally. Reasons it may be FALSE include the remote host not being reachable, the service running on the remote host not being available, or the service forbidding write access to the data (such as for "On The Web" calendars). Backends are responsible for updating this themselves. Clients are responsible for disabling the relevant UI elements when this property is FALSE. Under this scheme, client applications don't need to know about network or service availability -- just whether the backend can currently handle a particular user action. I think this simplifies things greatly. Matt _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
