GNOME Bugzilla – Bug 767914
Offer a simple mechanism to introspect the available providers and services
Last modified: 2016-07-14 17:13:33 UTC
Configuration and deployment tools like Fleet Commander [1] want to have an user interface to pre-configure accounts. This user interface will likely be different from gnome-control-center because it will only create a skeleton representing certain aspects of an account but leave out details like the identity and presentation-identity. It will be convenient if the various keys used by the providers are consolidated in an easy to parse (for both humans and machines) format. The Fleet Commander UI can read this file and create the account skeletons accordingly. Currently, one has to read the C code of each provider to gather this information, which involves human intervention. libgoabackend.so can embed this file as a GResource, while Fleet Commander can keep a copy and update it periodically. I don't expect the keys to change too frequently, so this shouldn't be too bad in practice. I am currently thinking of something like this: [google] MailEnabled=true CalendarEnabled=true ContactsEnabled=true ChatEnabled=true DocumentsEnabled=true PhotosEnabled=true PrintersEnabled=true This is (a) easy for humans to update, (b) easily parsable with only GKeyFile and (c) matches the accounts.conf syntax. Other options are JSON and XML since we already link against json-glib and libxml2. [1] https://github.com/fleet-commander
For fleet-commander the easiest way to get the data would be JSON. Almost all our files are JSON based.
Created attachment 331082 [details] [review] List services offered by each provider in machine & human readable form This is a key file where each group represents a provider and contains all the Enabled keys (ie. switches) supported by it. There are some complexities, though. The chat accounts are a bit special in the sense that there is only one 'telepathy' factory to deal with all the protocols (Jabber, SIP, etc.). The 'telepathy' factory creates GoaProviders at run-time based on the Telepathy backends available - Jabber is represented as 'telepathy/jabber', SIP as 'telepathy/sip', etc.. Given that the telepathy / libpurple bridge (ie. telepathy-haze) can expose dozens of unexpected protocols via libpurple plugins, it is impossible to exhaustively cover all of them. One option is to list only the most relevant chat protocols. Or we can ignore them altogether since GNOME is slowly moving away from Telepathy and instant messaging these days.
Here is another idea ... Instead of describing all the GoaProviders in a static key file and then making the gnome-online-accounts code use it, how about writing a small utility which will generate the key file based on the GoaProviders (and Telepathy backends) installed on the system? Being able to introspect the GoaProviders at run-time and generate a description seems like a generally useful thing to do. Tools like fleet-commander can even choose to generate this description during their build. Or they can generate it beforehand, have it committed to Git and manually update from time to time. The first option wouldn't be possible without introspection.
Created attachment 331230 [details] Tool to introspect available GoaProviders and their services
Created attachment 331327 [details] Tool to introspect available GoaProviders and their services Improve the workaround for bug 674885
Created attachment 331524 [details] [review] examples: Introspect the providers Pushed to master.