Re: Online Accounts panel for 3.2

[David Zeuthen <zeuthen gmail com>]

Hi,

On Mon, May 16, 2011 at 12:55 PM, Will Thompson
<will thompson 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