Re: Online Accounts panel for 3.2
- From: Alberto Mardegan <mardy users sourceforge net>
- To: desktop-devel-list gnome org
- Subject: Re: Online Accounts panel for 3.2
- Date: Wed, 20 Apr 2011 10:08:51 +0300
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
- 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)
- thin wrapper around the signon D-Bus API; see the SSO daemon description
SSO daemon (signon)
Dependencies: Qt, libcryptsetup
- Secure storage of user credentials
- Provides authentication tokens to applications
- SASL plugin, OAuth and plain password plugins are available; more can/should
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
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,
http://blog.mardy.it <-- geek in un lingua international!
] [Thread Prev