Hi, On Mon, May 16, 2011 at 12:55 PM, Will Thompson <will.thomp...@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. > 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? 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. > If the user's connected to Google *anyway* for XMPP, it makes sense to > use the XMPP mail notifications, rather than maintaining a separate > connection. Ditto IMAP and Evolution. (Inevitably there will be services > where the IM protocol doesn't do mail notification: I guess Facebook is > a likely example here.) > > Having some kind of commonality between the different sources of mail > notifications would be a big win for the Shell, of course. It would be > great for it not to have to care whether the notifications were > piggy-backing on an IM protocol, on an IMAP IDLE session, or anything else. 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. > 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. 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. Thanks, David _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list