Re: Online Accounts panel for 3.2

Hi David,

On 04/19/2011 05:42 PM, David Zeuthen wrote:
I did briefly look at
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,

-- <-- geek in un lingua international!

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