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

[Matthew Barnes <mbarnes redhat com>]

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