Re: Online Accounts panel for 3.2



Belatedly,

On 02/05/11 14:14, David Zeuthen wrote:
> The workflow in an app (such as Evo) would be like this
> 
>  accounts = goa.get_accounts_of_type('mail')
>  for a in accounts:
>    if a is OAuthBased:
>      (oauth_access_token, oauth_access_token_secret) =
> a.OAuthBased.GetAccessToken()
>    elif a is OAuth2Based:
>      oauth2_access_token = a.OAuthBased2.GetAccessToken()
>    elif ...
> 
>    if a is GoogleAccount:
>      use API from http://code.google.com/apis/gmail/
>      with one of the credentials you got above
>    elif a is YahooAccount
>      use API from http://developer.yahoo.com/mail/
>      with one of the credentials you got above
>    elif ...
> 
> 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.)

Cheers,
-- 
Will


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]