Re: Online Accounts panel for 3.2

Hi David,

On 04/19/2011 04:08 PM, David Zeuthen wrote:

One of the things I'm looking at doing for 3.2 is the Web Accounts panel:

See the "Current status" section in that page. We already have all of this (and more) in MeeGo, and I'm willing to support any efforts in bringing this to Gnome.

I sat down last week with one of the designers, Jon McCann, and we
came up with what we both think is a really nice user experience. It
is described in [1] for now - will move to the wiki soon.

Implementation-wise, I can see this as a very minimal daemon / library
that sits below libsocialweb, Telepathy, e-d-s and other APIs (e.g.
these libraries/frameworks would use this new framework) that is
dealing data online accounts.

In MeeGo we chose two split the thing into two: account framework, which simply consists of descriptions of providers and sources (which we call "services"), and a library wrapping a SQLite DB for accounts settings, where applications can read/store accounts settings (not the passwords).

The provider and services are described by XML files, which can be installed in predefined directories. This allows for expandability: to support a new service, you just need to install a package which adds a service XML file. The service XML files not only describe the service (icon, name and provider) but also contain a default value for account settings; the account library uses these settings as fallback when a settings has not been explicitly written in the DB -- this is all transparent to the application. The point of this is that you don't want to ask the user for the address of the IMAP server of GMail: we can write it in the service XML file.

The accounts library support change notification via D-Bus, so that when a setting in the GMail account has been modified, all applications interested in the e-mail service type are notified and can reconnect the account.

This daemon / library would

  a. have a notion of "source types"
    - email source

  b. have a notion of providers that can be added removed by the
    end user
    - Google (for accounts at and Apps For Your Domain)

  c. provide a concrete list of providers and what sources the
     instance of the provider supports. For example, for my setup, I
     would have the following

    - zeuthen gmail com (an instance of the Google data provider)
      - Mail (email source)
      - Contacts (contacts source)
      - Calendar (calendar source)
      - Chat (chat source)

It's similar to what we have, except that we don't hardcode the list of available sources in the provider file. It's the source, who tells what provider (and source-type) it belongs to.

This "screenshot" shows an example where the david fubar dk account
needs attention (suppose that the password has been changed from
another system). In this case, I think the desktop would show the user
a notification saying "The account david fubar dk needs your
attention" and upon clicking on it, the user is taking to the
control-center pane above.

Mmm... that's one option, though I'd rather like that by clicking on the notification you directly go to the login screen where you can enter your password.

And one thing that I heartily recommend you based on experience: do *never* let the user change the username once the account has been created. This saves you a lot of trouble.

This daemon/library thing, let's call it GOA (Gnome Online Accounts),
would _not_ be a mechanism to access any of these services. But it
would provide e.g. libsocialweb, telepathy, e-d-s and so on with
either the username/password combo or the OAuth token, whatever is

And for this we have the SSO framework in MeeGo. It's one daemon, that stores the user credentials on an encrypted partition which is mounted only when the user is identified (in our device we'll use the SIM card for this goal, in the Gnome desktop it could be the lock-screen password).

Passwords are generally not given back to applications; instead, signond (the SSO daemon) loads a plugin specific to the authentication method being used (SASL, OAuth, Google, etc.): the plugin gets the passwords, and uses it to compute a response to give back to the client. This response can be a response that the client must give back to the remote server in a SASL challenge, or a token that can be used to login. In cases where the authentication plugin performs the authentication with the remote server, in case the password is wrong it will itself inform signond, which in turn will invoke a UI to prompt the user for a new password. If instead the plugin is simply computing responses without having knowledge if the password is correct, the application will get an error and it can retry the authentication with a flag which tells signond to ask the user for a new password before computing the response.

I would imagine Telepathy/Empathy to use GOA to get the Chat accounts
that is configured in GOA (in the above example, it would be Google
Talk from zeuthen gmail com and Facebook Chat for davidz25). I would
use an Empathy specific preferences window (not appearing in
gnome-control-center I think) to add e.g. my ICQ account.

Telepathy has already been modified in MeeGo to support the accounts and SSO frameworks.

There are of course security / implementation considerations
(password/auth token hygiene, should we treat the desktop like it's
not a single security context when it really is?) here - all of that
comes next.

We addressed all security concerns already; feel free to ask in case you have some doubts.

Technically, I'm proposing that we add a GOA module with

  - a daemon, goad, that implements the org.gnome.OnlineAccounts interface
  - a library, libgoa-1.0, that is used to speak to goad (but an app can

I'm afraid you are a bit too optimist; or maybe it's just me who likes making things more complicated. :-)

  - initially GOA will know about the following source types
     - mail
     - contacts
     - calendars
     - chat

Also the {source,service} types should be installabe XML types, IMHO.

  - initially GOA will have support for a couple of online providers (Google,
    Yahoo! comes to mind) as well as "generic servers" (initially, say email
    servers (IMAP/SMTP) and iCal/Jabber servers).

Our framework doesn't have any knowledge about specific account types. It's all handled in XML files and in authentication plugins (OK, OK, we also have account UI plugins for creating/configuring accounts, but we actually could have done without them and just have QML UIs -- and anyway these plugins are very trivial).

Timing-wise, I'm not sure how it's going to work - I can have goa
ready somewhat soon (it's actually a rather simple daemon/library) but
I'm not sure if that's enough time for everyone to use it for 3.2...

I would encourage you not to start everything from scratch. As I said, we have it all done already (except the UI parts, which are not open source):

I'm sure that especially for the SSO part there'll be need for work in order to adapt it to the desktop; but it will still be far quicker than rewriting everything. The accounts part should be already well working on the desktop.

We are using the meego-dev mailing list for development of the frameworks, but as I wrote in my e-mail "Re: Planning features for 3.2" (date: 09/04/2011) we can move it to a different infrastructure ( if there's interest for it.


P.S.: I believe that GtkSwitch is perfect for this use-case. :-)

-- <-- geek in un lingua international!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]