Hi, On Fri, May 13, 2011 at 7:34 AM, Will Thompson <will.thomp...@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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list