On Wed, 2012-04-04 at 13:11 -0400, Matthew Barnes wrote: > 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. Nitpicky, but what happens if a backend has to deal with multiple hosts? The only example I can think of at the moment, and it's a stretch, is the Google Contacts backend. It connects to one host for authentication, and a different one for Contacts operations. Most of the time, GOA will take care of authentication, so this really is a tiny corner case, but I guess it's worth considering. I suppose we would just use the Contacts operations host for the purposes of "socket-connectable", and treat failure to connect to the authentication host as a transient authentication error. > "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. I might be tempted to give the user feedback about why a backend is _not_ writeable (somehow, perhaps a "writable-reason" enumerated property). This could be useful when setting up a backend: the backend might report itself as non-writeable, but the user would not know whether this is because they've made a typo in the backend's URI, or because they've used a read-only URI instead of a writeable one. Or something like that. Overall, this set of properties seems to simplify things nicely though. It also fits in well with the offline buffering stuff Milan and I have been discussing (with a few other people CCed). Philip > 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 > evolution-hackers gnome org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers
Attachment:
signature.asc
Description: This is a digitally signed message part