Re: GNOME Online Accounts extensibility

[David Zeuthen <zeuthen gmail com>]

Hi,

On Sat, Oct 8, 2011 at 12:11 PM, Ted Gould <ted gould cx> wrote:
> So to be clear, you see GOA's configurability to be in setting up new
> account groups, but new protocols.  So I could add "Corp. Account" but
> if my corp. uses a protocol that GNOME OS doesn't use otherwise, I
> couldn't add this.  Trying to understand what configurability you expect
> in the future.

The way to look at GOA is that it's just one provider of accounts. As
I said, GOA is by no means a substitute for having a separate way to
configure an app for accounts - if it was, then GOA would be a choke
point in this way: it just makes no sense to add protocol-support in
both the app and in GOA to make things work - you end up with ugly
dependencies between the app, libgoa and the running goa-daemon(8)
instance. Which makes it really hard to get anything done. So just
from a technical point of view the "I want to use GOA to configure
everything" is a non-starter, I think.

You should think of GOA as something that the app can optionally
depend on to make using 'suites' of services (e.g. Google, Yahoo) just
work in the sense that you logon once and then the auth token is used
for all services, e.g. mail, chat, calendar etc. And no-one says that
only GNOME apps (such as Evolution) can use this - no one is
preventing e.g. Thunderbird from consuming the same kind of data.

The other thing is that we do not want the UX in the Online Accounts
preference pane to look like this

 http://people.freedesktop.org/~david/lots-of-account-types-that-i-don't-know-about.png

Not that there's anything per-se wrong with that kind of UI in Empathy
(the same way there's nothing wrong with all the Chrome you find in
e.g. Gimp) - we just don't to expose the user to it if we can avoid
it. The idea of Online Accounts has been from the start that this is
something the user sees in either the OS installer or as part of some
"Initial Setup" experience, see e.g.

 https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup

So you ask about extending GOA and I've already explained a bit about
that upthread. It's not that I'm 100% opposed to it, heck as I said we
used to read config files, and double-plus-heck, the code is already
using gio extension points, see

 http://developer.gnome.org/goa/unstable/GoaProvider.html#GOA-PROVIDER-EXTENSION-POINT-NAME:CAPS
 http://developer.gnome.org/goa/unstable/GoaProvider.html#goa-provider-get-for-provider-type

we just don't read any GIO modules just yet.

As I said upthread, the only reason this is so is basically because a)
providing a stable API for extensions is expensive; and b) providing a
stable config file format is also expensive; and c) it's too easy to
abuse to create substandard UX in the Online Accounts preference pane.

Well, where to go from here? a) and b) will clearly be non-issues
around 3.4 or 3.6 as things stabilize [1]. It's more c) I'm concerned
about. To resolve this we need to work with the designers to make sure
that the UX can scale in the presence of many different account types.

Either way, I don't get why you are so concerned about whether GOA can
be extended. If you buy into the idea that apps will always need to
have a separate panel for non-mainstream accounts then... then the app
can provide the extension point and config-file merging from
.d-directories.

    David

[1] : note that we said the same about GVfs and GVfs backends are
still private GNOME API 3 years later. Which turned out to not really
be a problem even though everyone whined about it about the fact that
there is no stable GVfs API. But it works really well for GVfs, heck
we got all the interesting parts _in the GVfs tree_ instead of them
being random 3rd party things seeing less testing. It's similar to how
the Linux kernel works.