I will try to reply at the risk of taking this thread on a wild
On Thu, Mar 26, 2015 at 04:49:21PM +0000, Alberto Ruiz wrote:
Perhaps the solution here is to allow external GOA providers and
such provider a dependency of the maps app?
That quickly falls apart if a provider offers multiple services and an
application corresponding to one of them is missing.
We already explored the option of splitting the providers into
loadable modules that can then go into separate sub-packages . I
wrote the code for that, but, eventually, Ray Strode convinced me that
it is a bad idea.
And, I definitely don't want out-of-tree external providers. Offering
a stable plug-in API is too much trouble for very little gain.
Third-party application developers have expressed concerns about
losing their own branding if they use GNOME's application keys, and it
will be ugly to have multiple providers show up for the same service
but using different keys.
There is a lot to be improved in the way applications interact with
online accounts and providers, but I don't think we have the necessary
infrastructure to do it, yet. eg., currently there is no way to
reliably figure out which applications might be using an account. Once
we have that then we could probably use it to show or hide the
providers depending on what is present on the system. I can imagine a
built-in list of known GNOME applications inside g-o-a, and a way for
an application to express its interest in a certain provider.
But all that is vaporware at the moment, and I don't want to get into
designing something before the technical foundations are ready.
To be honest, our online accounts story is still in its infancy. We
are still far from achieving a ChromeOS like experience. We are
slowly getting there, and once we are a bit further down that road,
we can figure out a story for third-party developers / applications.
We need a little more maturity before we can do that.