GNOME Bugzilla – Bug 661117
Provide a generic "Other" account type for popular generic protocols
Last modified: 2013-03-22 13:53:40 UTC
The idea is to provide an "other XMPP provider" for Jabber and XMPP, an "other mail provider" for IMAP/POP3/SMTP and an "other calendar provider" for—well—calendars, webcal et al. As we're never going to provide a dedicated solution for each possible server providing any of the above features, we can just try to cover the generic cases where people fill in their provider's details. As these would all have a single well-defined purpose, the UI can be kept simple and apps like Empathy and Evolution can easily handle the accounts.
Sounds good to me. And as mentioned on d-d-l earlier today I already have code for doing this for IMAP and SMTP - see http://people.freedesktop.org/~david/gen-mail-1.png http://people.freedesktop.org/~david/gen-mail-2.png http://people.freedesktop.org/~david/gen-mail-3.png http://people.freedesktop.org/~david/gen-mail-4.png From a technical point of view - we will only support password authentication and we will store the password in the keyring - we will add a new .PasswordBased interface, similar to http://developer.gnome.org/goa/unstable/gdbus-org.gnome.OnlineAccounts.OAuthBased.html http://developer.gnome.org/goa/unstable/gdbus-org.gnome.OnlineAccounts.OAuth2Based.html but just with a GetPassword() method. Like e.g. http://developer.gnome.org/goa/unstable/gdbus-org.gnome.OnlineAccounts.OAuthBased.html#gdbus-method-org-gnome-OnlineAccounts-OAuthBased.GetAccessToken we will log usage of GetPassword(). - we should verify that the stored credentials work whenever Account.EnsureCredentials() are passed - this includes connecting to the endpoint and using the protocol (e.g. for IMAP, it means doing the LOGIN command). We should also validate TLS certs, if any. We could either just write a mini-client for this (for IMAP it's very simple). For XMPP, I don't know, maybe we should use Telepathy for this. Dunno.
Btw, we should also ask the user for his email address as the first step - and from there figure out the IMAP/SMTP servers from the same database as Thunderbird (and I think, Evolution nowadays) is using.
(In reply to comment #1) > For XMPP, I don't know, maybe we should use Telepathy for this. Dunno. Of course you should. We have 2 options here: A) Just create the Telepathy account directly into mission-control using tp-glib API (as empathy-accounts does). The password should be stored in gnome-keyring directly using the same schema as Empathy's and it will just work. B) Expose the account properties in GOA using some standarised keys (bug #653269) and feed them to Empathy's MC plugin. B) is a bit of extra work and add an extra layer but is more coherent with the way GOA is currently working.
Thinking about it ( https://bugzilla.gnome.org/show_bug.cgi?id=653269#c12 ) I think B) is indeed the way go to.
I am not exactly sure what is the objective of this bug. If it is about taking a yes/no decision about whether we want to support generic protocols -- IMAP/SMTP, XMPP, etc., then I think the answer is "yes". Now, instead of cluttering this single bug with patches for all the protocols, lets do them in their separate bugs. All existing requests related to generic protocols now depend on this bug. (Assuming that this one was about deciding whether to do so or not.) Some days ago, I started working on a IMAP/SMTP provider (see 692736) based on the code that David had written earlier. So can we close this as RESOLVED FIXED?
3.8 has a IMAP / SMTP provider (see bug 692736), and 3.10 will have providers for XMPP, IRC, etc. (see bug 696281). Assuming that this bug was about making a policy decision about supporting such providers, I am marking this as RESOLVED FIXED. Lets use the specific bugs for tracking the patches to add each provider.