Re: Online Accounts panel for 3.2

[Will Thompson <will thompson collabora co uk>]

On 13/05/11 15:20, David Zeuthen wrote:
> 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

How is this implemented at the network level? Ah, I just found the footnote:

> [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.

More on this story later in this mail, but: out of interest, were you
aware that Telepathy already supports mail notifications on (off the top
of my head) Google Talk, Yahoo!, MSN and AIM?
<http://telepathy.freedesktop.org/spec/Connection_Interface_Mail_Notification.html>

> 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?

No, not really.

To check I'm not misunderstanding: you're proposing that Gabble
(Telepathy's XMPP backend), rather than using its XMPP library to open a
connection to the server, would call out to GOA, which would have its
own implementation of the XMPP session initiation, certificate checking,
authentication, etc. code; once the session is established, GOA would
hand back an FD which Gabble would have to assume was in the right state
to pick up right after the authentication step?

This doesn't sound like a good idea to me at all. Do you really want to
bake detailed knowledge of all these disparate protocols into GOA?
Surely it makes more sense to keep the generic IMAP and SMTP code in the
mail client, the XMPP code in the XMPP service—and by inevitable
extension, the AIM code in the AIM service, etc.?

File descriptor passing is cool and all, but I really don't think it's
appropriate here for (say) the XMPP connection. Establishing a session
is not actually trivial (and in the future it could get even less
trivial—for example, we might want to support BOSH
<http://en.wikipedia.org/wiki/BOSH>). But in any case, it's already been
implemented, with the necessary hooks to plug into GOA for the SASL
authentication step already in place. These hooks have been used to
integrate with GOA-esque services (including Bisho on MeeGo Netbook, and
libaccounts and signon, and of course Gnome-Keyring) without needing to
include knowledge of all N keyring implementations in all M
protocol-specific Telepathy backends.

For what it's worth, this is what the Telepathy D-Bus API for SASL looks
like:
<http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html>.
>From my brief research into the world of IMAP, I think something similar
could be done there too. So then GOA's Google backend would understand
the custom SASL mechanisms Google uses on various protocols, but would
not need any details of the protocols themselves.

> 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

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.

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.

>    - 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...

Of course, this is unavoidable. I'd just like to avoid it where it's not
needed. :)

Regards,
-- 
Will