Re: Online Accounts panel for 3.2

[David Zeuthen <zeuthen gmail com>]

Hi,

On Fri, May 13, 2011 at 7:34 AM, Will Thompson
<will thompson collabora co uk> wrote:
>> For example, for GMail, you can use the OAuth token when
>> authenticating the IMAP and SMTP connection cf.
>> http://code.google.com/apis/gmail/oauth/
>
> This big-switch-statement-in-every-application approach concerns me: it
> would be better to essentially delegate the SASL exchange to GOA. Doing
> so would minimize the number of components that need to be updated to
> support a new custom authentication mechanism for an otherwise standard
> protocol. Obviously I'm going to use Telepathy and XMPP for an example
> of why :), but I think the same reasoning holds for IMAP, based on that
> link above, and other services.
>
> Google Talk is just another XMPP server that happens to support an
> X-GOOGLE-TOKEN SASL mechanism. Facebook is just another XMPP server
> which supports an X-FACEBOOK-PLATFORM mechanism. Gabble (the XMPP
> backend for Telepathy) doesn't implement either mechanism: it just
> exposes the SASL challenge over D-Bus. Empathy has a client for that API
> that uses gnome-keyring to get the password; on MeeGo Netbook there's a
> client that implements X-FACEBOOK-PLATFORM. In a GOA world, we'd ideally
> like to avoid the handler having to have a big switch statement for
> every supported account type: GOA already has Google-specific code, and
> it already knows that this account is a Google account, so it could
> implement the X-GOOGLE-TOKEN mechanism in the Google-specific code there.
>
> Then, to support a hypothetical Flickr XMPP/IMAP/&c service with
> X-PICTURES-OF-CATS authentication, we'd only have to add Flickr code to
> GOA; we wouldn't have to touch the authentication code in Evolution or
> Telepathy.
>
> (This is one beef I have with Nokia's Signon framework: the Telepathy
> bridge for that has to have a big switch statement for each supported
> account type, on top of the account type-specific plugins for signond.
> It would be nice to not repeat that.)

Right, I thought about that. We basically have a N times M times P problem, e.g.

 - N providers with varying APIs
   - Google, Yahoo, ...
 - M kinds of services we want to support
   - Mail, Chat, Calendar, Contacts, Storage, ....
 - P number of libraries/frameworks or apps
   - libs: e-d-s, libsocialweb, libfolks, Telepathy
   - apps: evolution, thunderbird, empathy, nautilus-send-to

To start with what the user sees, see the mockups here

 http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00107.html

Basically each Switch in that UI correspond to the M kinds of services
- e.g. each configured account has up to M of them. Now, I'm saying
"up to M" because we obviously don't want to show

  [ON   ] Chat

for your Google account unless it actually means you can chat in GNOME
with it (e.g. the Shell and Empathy supporting it - which basically
comes down to if Telepathy is supporting it).

Btw, already at this point, it should be clear why all this needs to
happen in the well-defined sandbox that is GNOME: we can't go add
support for providers or kinds of services willy-nilly - it all has to
be coordinated in a way so it all works. For chat, it means
coordinating GOA and Telepathy. For other kinds of services (like Mail
or Calendar), it may be harder - especially if it involves
coordinating the effort with multiple apps (such as both Evolution and
Thunderbird) or multiple libraries.

So my current experiments [1] actually reflect this thinking .. in
fact, right now I'm working on the Mail experience, basically trying
to implement something like these mockups

 https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Email

For that, I have code (hundreds, not thousands of LOC) in the Shell
that talks to this interface exported by GOA

 http://people.freedesktop.org/~david/goa-20110512/gdbus-org.gnome.OnlineAccounts.Mail.html
 http://people.freedesktop.org/~david/goa-20110512/gdbus-org.gnome.OnlineAccounts.Mail.Query.html

It works great, see

 http://people.freedesktop.org/~david/mail-notif-1.png
 http://people.freedesktop.org/~david/mail-notif-2.png
 http://people.freedesktop.org/~david/mail-notif-3.png

I was thinking of adding a method such on the
org.gnome.OnlineAccounts.Mail interface like this

 GetAuthenticatedImapConnection (OUT h file_descriptor);
 GetAuthenticatedSmtpConnection (OUT h file_descriptor);

that your mail application can use. For Chat, my thinking is that we
could have something similar e.g.

 GetAuthenticatedXmppConnection (OUT h file_descriptor);

that Telepathy can use. Does that sounds OK?

Anyway, how we balance where to put implementations is a very hard
question that I'm still thinking about. I'm leaning towards

 - For every service type (Mail, Calendar, etc.) should provide a
   "simple" interface that the Shell can use for notification

   - One example is the org.g.OA.{Mail,MailQuery} interfaces

   - Unless of course there's a good solution there already - for e.g.
     Chat we have Telepathy which is awesome so all we provide is
     GetAuthenticatedXmppConnection (OUT h file_descriptor)

   - For mail, calendar.. it's a harder story.. we have e-d-s but I'm
     just not sure it's the API we want - so we might not want to use
     it (that said, e-d-s can still add support for GOA). I don't know.

 - If the service type sports one or more standardized protocols (such as
   IMAP, SMTP, XMPP etc.), GOA should provide a way to get an authenticated
   connection that can be passed to the app (as a file descriptor)

   - but it could also be that a provider P does not provide that kind of
     access.. for example, for Mail, Facebook might not have an IMAP server.
     So for that, the app/library will need the giant switch...

Btw, one problem with GetAuthenticatedXyzConnection() is that things
like proxy settings (or things like SSH tunneling that Evo supports)
becomes impossible (or at least very hard). But I don't think that's a
problem, such things shouldn't be done at the app-level - it needs to
be done at the OS level and our core library stacks (for GOA's case,
libgio-2.0) should use this information.

There are two flows that are very important and will need to be
documented in GOA

 F1 how to add support for a new provider (say, the next Facebook)

 F2 how we add a new "kind of service" in addition to Mail, Chat, etc.
    For example, Music is one option here with both Amazon and Google
    having cloud music things... would make sense to have e.g. Rhythmbox
    just pick that up from GOA automatically

That was the technical part. Then there's also all the legal and Terms
Of Service issues with providers. Which may be the harder part.

For 3.2, I think I'd like to start with only a very few providers and
not too many service types ... I'm personally focusing on Email and
Calendar - I know people are interested in at least Contacts and Chat
too. I think it might be easy enough to do Chat if all we need to do
is the GetAuthenticatedXmppConnection(). Shouldn't be too hard to
implement in GOA.

Anyway, I was planning to write a long blog entry about all this and
probably still will. But this mail reflects most of my thinking on
this very complex problem. Hope it helps.

Thanks,
David

[1] : Emphasis on _experiment_ here.. for production use, maybe we
should use the IMAP client code from Evo instead of the simple
hand-rolled IMAP client that I put together in a couple of days. Then
again, I don't know.