Hey, One of the things I'm looking at doing for 3.2 is the Web Accounts panel:
http://live.gnome.org/ThreePointOne/Features/Sharing http://live.gnome.org/Design/SystemSettings/Profile 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. This daemon / library would a. have a notion of "source types" - email source - calendar source - chat source - photos source - contacts source - ... b. have a notion of providers that can be added removed by the end user - Google (for accounts at google.com and Apps For Your Domain) - Yahoo/Flickr - Exchange - Facebook - ... 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 - zeut...@gmail.com (an instance of the Google data provider) - Mail (email source) - Contacts (contacts source) - Calendar (calendar source) - Chat (chat source) - da...@fubar.dk (an instance of the Google data provider) - (works because fubar.dk is using Google Apps For Your Domain) - Mail (email source) - dzeut...@yahoo.com (an instance of the Yahoo! data provider) - Flickr! (photos source) - (I specifically unchecked mail here because I don't want the spam that is in that email account that I never use) - davidz25 (an instance of the Facebook data provider) - Messages (email source) - Events (calendar source) The information in c. would map exactly to what the "Web Accounts" UI would display: +------------------------------------------------------------------+ | All Settings | +------------------------------------------------------------------+ | +-------------------------------+ Google Account | | | [Go] zeut...@gmail.com | | | | [Go] da...@fubar.dk (!) | Username: david____________ | | | [Y!] dzeut...@yahoo.com | Domain: fubar.dk_________ | | | [Fb] davidz25 | | | | | Use this account for: | | | | | | | | [ON ] Mail | | | | [ OFF] Chat | | | | [ OFF] Contacts | | | | [ OFF] Calendar | | | | | | +-------------------------------+ (!) Authorization expired. | | | [+] [-] | Please login again. | | +-------------------------------+ [Login] | +------------------------------------------------------------------+ This "screenshot" shows an example where the da...@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 da...@fubar.dk needs your attention" and upon clicking on it, the user is taking to the control-center pane above. 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 appropriate. 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 zeut...@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. 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. Technically, I'm proposing that we add a GOA module with - a daemon, goad, that implements the org.gnome.OnlineAccounts interface on a well-known object /org/gnome/OnlineAccounts and owns the well-known name org.gnome.OnlineAccounts (all this is on the session bus). Additionally, this daemon would notify the user if attention is needed (e.g. reauth) using org.freedesktop.Notificatins / libnotify. - a library, libgoa-1.0, that is used to speak to goad (but an app can also just use the D-Bus interface if it wants to). This library is what libraries/frameworks can use to get the information stored in goa. It would be a classic GObject-ish library providing both sync and async access to the data. It would also be introspectable so it's usable from e.g. Python or gjs. - a control-center panel to configure GOA - initially GOA will know about the following source types - mail - contacts - calendars - chat - 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). Once this is in place, apps like Evolution and libraries like libsocialweb can start using this. FWIW, I'm planning to use this for the GNOME Shell calendar drop-down so the shell can easily show events from my zeut...@gmail.com calendar (configured in GOA) without involving Evolution (I've got most of that code written already - all I need is a way to actually get the accounts to use instead of me hard-coding it.) 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... There's a bit of overlap with other things here so that's why I'm starting this discussion on desktop-devel-list now. I'm pretty convinced that we need something really low-level and centralized so e.g. you don't have to type in your Google password 3+ times (as is the case for me today)... and I'm also pretty convinced it has to be a GNOME project because the set of source types we offer greatly depends on whether the GNOME app(s) in question supports that source (e.g. no point in showing an "Events" switch for your Facebook account if your calendar app don't know how to use it). Anyway, lots of information in this mail - sorry about it being so long! Thanks, David [1] : Basically, it would be ideal if the workflow was something like - User presses "Add Account" in the control panel - User selects "Google Account" and enters his identity - User authenticates (using OAuth e.g. in the browser and possibly using CAPTCHAs and possible two-factor auth cf. http://tech.icrontic.com/news/how-to-enable-two-factor-authentication-on-your-google-account (For extra credit we only launch a browser instance if we really need it. I think Google at least supports a "Mobile Device" profile that does this at least for CAPTCHAs.) - User toggles, using GtkSwitch-like UI, what parts of this Google Account instance that he wants to use, e.g. [2] [ON ] GMail [ON ] Contacts [ON ] Calendar [ON ] Google Talk [ OFF] Picassa - If you later need to re-authenticate (just like the GMail web interface often makes you log in again) then we should somehow show a notification in GNOME Shell that directs the user to the system settings panel (see below) Of course, this should work with more than your Google Account. If you use your Yahoo! account, it would look like this [ OFF] Yahoo! Mail [ON ] Flickr We'd probably also want it to work with "generic services", e.g. have a way to add unbranded IMAP/SMTP/LDAP/iCAL/Jabber servers. Note also how the branded services (Google, Yahoo!) uses branded names Picassa and Flickr instead of the generic "Photo Service". Note also that you can have multiple instances of the same type - e.g. I'd have both da...@fubar.dk and zeut...@gmail.com as Google Accounts. But I'd only use Mail for the da...@fubar.dk one - I don't want my calendar app to show the da...@fubar.dk calendar because I don't use it. Similarly, I don't want to see my dzeut...@yahoo.com mail because it only has spam in it. So that's why there are GtkSwitch for turning services on and off... [2] : Please don't get too worked up about me mentioning GtkSwitch - it's not the point. If using check-boxes is better, we'll just do that! _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list