On Wed, 2012-04-04 at 21:25 +0100, Philip Withnall wrote: > 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.
Agreed. More broadly I'd say "socket-connectable" should point to where the data lives. If that's not reachable then there's really no point in authenticating, whether _that_ host is reachable or not. > 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. That's worth considering, though it might already be partially covered just by backends returning error messages on failed operations as per normal. That includes open(). > 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). Good! That at least validates I'm not _completely_ off the mark. :) Matt _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
