Re: Online Accounts panel for 3.2
- From: Will Thompson <will thompson collabora co uk>
- To: desktop-devel-list gnome org
- Subject: Re: Online Accounts panel for 3.2
- Date: Fri, 13 May 2011 12:34:38 +0100
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]