Re: Online Accounts panel for 3.2

[Alberto Mardegan <mardy users sourceforge net>]

Hi David,

On 04/19/2011 05:42 PM, David Zeuthen wrote:
> I did briefly look at http://gitorious.org/accounts-sso/accounts-glib
> but quickly got lost as that appears to be just the client-side GLib
> glue. And some of the other stuff looked pretty specific to Meego.

No, it isn't just a glue thing :-) It's the full thing, its only dependencies 
(beside GLib) are SQLite and D-Bus.

> Can you give a short overview of exactly what components that you've
> written that GNOME would use (including their dependencies and whether
> it's a per-session daemon, per-system daemon or shared library), what
> GNOME would need to write itself and how it would fit together with
> the UX that I've described? I mean, obviously accounts-glib would be
> an external dep and obviously we'd write our own GNOME Control Center
> panel ... but what else? I'm asking mostly to figure out what
> additional dependencies this would add to GNOME if we were to use it!

Sure. So, let's start with what we have:


  Account library (libaccounts-glib)

Dependencies: GLib, SQLite, D-Bus
Provided functionality:
- enumeration and parsing of provider, service and service-type XML files
- reading/writing of accounts settings (with fallback to settings hardcoded in 
the service XML files)
- change notification mechanism


  SSO library (libsignon-glib)

Dependencies: GLib, D-Bus
Functional dependencies: SSO daemon (the D-Bus service)
Provided functionality:
- thin wrapper around the signon D-Bus API; see the SSO daemon description


  SSO daemon (signon)

Dependencies: Qt, libcryptsetup
Provided functionality:
- Secure storage of user credentials
- Provides authentication tokens to applications
- SASL plugin, OAuth and plain password plugins are available; more can/should 
be written

I'm sure that some people had a repulsive reaction when reading the word "Qt". 
:-) But it's not so bad as it seems: the daemon does not generate any UI (and is 
actually built without the QtGui module), it requests UI interactions via D-Bus 
and therefore the UI itself could be written using whatever tooltik.
If the very fact that the daemon itself is written in Qt is unacceptable, it can 
also be rewritten in another language/toolkik -- but I personally wouldn't be 
interested in this exercise (though I would still be available for helping the 
development team).

Both libaccounts-qt and libsignon-qt variants exist for these components, and 
even if this is not strictly interesting for Gnome developers, it's one more 
thing to consider: it could help in sharing the same user data with the KDE 
desktop and with Qt applications.


Now, the list of what is missing:

- Control panel applet
- Account UI plugins (unless the setup flow is hardcoded in the control panel 
applet); according to how the CPA is designed, these could be just some XML/json 
files describing the UIs
- SSO UI: a daemon exposing a simple D-Bus API; it will take care of showing 
notifications/login dialogs to the user on failed authentications (or when the 
secure storage is unavailable)


Also note that the Accounts & SSO frameworks are orthogonal to each other, and 
you can use one without the other.

Hope this helped,
  Alberto

--
http://blog.mardy.it <-- geek in un lingua international!