Re: Online Accounts panel for 3.2

[David Zeuthen <zeuthen gmail com>]

Hey

On Mon, May 16, 2011 at 2:03 PM, Will Thompson
<will thompson collabora co uk> wrote:
> 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…

[...]

> 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.

If it's really that simple, apps can surely have the switch, no? I
mean, instead of GOA adding API that we might want to remove later? I
mean, for providers this information most likely depends on whether
OAuth 1 or OAuth 2 is needed so the added API would have to go on the
.OAuthBased or .OAuth2Based interface (instead of e.g. the
.GoogleProvider interface). and it would look weird to have a
GetGoogleToken() method on the .OAuthBased interface.

OTOH, if calculating the SASL response involves e.g. private API keys
like it does for calculating the IMAP SASL response, see

 http://code.google.com/apis/gmail/oauth/protocol.html

then... then I think GOA _will have_ to contain D-Bus API for doing
this.. because.. we might not want to add API for people to get the
consumer private key because that precludes us from supporting
services where the API key has to be kept a secret. I don't know. Then
again, such TOS are more or less incompatible with free software so
I'm not losing sleep if some downstream can't easily support them. I
don't know. Can of worms.

>> 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?

Right, it would affect anything using GOA. But that's just the way it
is, I think.

Cheers,
David