Re: Online Accounts panel for 3.2

[Will Thompson <will thompson collabora co uk>]

On 16/05/11 18:20, David Zeuthen wrote:
> Hi,
> 
> On Mon, May 16, 2011 at 12:55 PM, Will Thompson
> <will thompson collabora co uk> wrote:
>>> 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?
>>
>> No, not really.
> 
> That's fine and, sure, in retrospect probably easiest if GOA doesn't
> get involved with XMPP. I was mostly thinking out loud. And I was just
> under the impression that you actually asked for GOA to make things
> easier here.

Ah! My suggestion was, concretely: rather than

  method GetGoogleToken() → s
  method GetFacebookToken() → s
  method GetOAuthToken() → s

GOA could have either an API which resembles SASL, or…

>>
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html
>
> I don't think GOA needs to know about such interfaces at all - we just
> hand you either the OAuth (or OAuth2) token and you can do this
> yourself, yes?

… (thinking out loud) GOA could have a simple API for the degenerate
custom SASL mechanisms like X-GOOGLE-TOKEN where the client provides (a
hash of) the token when telling the server it's selected a mechanism,
and the server says yes or no:

  property SupportedMechanisms: as
  method GetToken(s: Mechanism) → s

Given that GOA already knows the account type etc., it already knows
what kind of mechanisms are appropriate. This would let the Telepathy
GOA plugin avoid needing specific knowledge of each custom XMPP server,
at the cost of GOA itself's providers knowing a little more than just
OAuth2, but not much: X-GOOGLE-TOKEN, for example, is (IIRC) sha1('\0' +
username + '\0' + token), which is to say SASL PLAIN.

> One thing to be aware of is that GOA might change a
> provider from e.g. OAuth 1.x to OAuth 2.x at any point (for example,
> Google appears to be switching to OAuth 2.0 but not all services have
> been switched over yet) - so we just need to ensure that whatever ends
> up interacting with GOA is ready for such a change.

Right. We have GNOME releases as kind of built-in synchronisation
points, I suppose. This might also affect things like libsocialweb more
acutely?

> I'm not sure this is really an optimization that is worth it - it
> seems to really muddy the picture a lot.... and I can imagine a future
> where we allow the user to choose what GMail labels to notify for -
> not sure how this would work with XMPP.

Good point. In any case: it's there if we want Hotmail/Yahoo!/other
webmail notifications with relatively effort.

>> But: I think this would be best achieved by having Evolution, Telepathy,
>> etc. implement a common API the Shell can monitor (or push their
>> notifications into GOA, so the Shell can listen to that), rather than
>> moving non-authentication-related network protocol code into GOA.
> 
> Sure, ideally GOA would only be concerned about dishing out tokens and
> not care about getting involved in the actual protocol used for each
> service. And with Telepathy it looks like it could work well.

Yup: great.

> But for Mail and Calendar I'm not so sure - so that's why I'm adding
> very simple interfaces to GOA that the shell can use for mail
> notifications and calendaring in 3.2 (As a side-effect, this gives you
> Mail notifications and Shell calendaring functionality even when Evo
> is not installed). Once we have a good story for Mail and Calendar in
> place, we can easily move it there.

I'd actually forgotten I had my calendars configured in Evolution until
I saw the beautiful agenda panel in the shell. :)

Cheers,
-- 
Will