Re: GNOME Online Accounts 3.34 won't have documents support

[Debarshi Ray <rishi is lostca se>]

On Wed, Jan 23, 2019 at 02:49:55PM +0000, Emmanuele Bassi via desktop-devel-list wrote:
> On Wed, 23 Jan 2019 at 14:21, Allan Day <aday gnome org> wrote:
> > If apps could provide their own keys that would certainly change the
> > picture (I didn't actually know it was a possibility.) It would also
> > change the nature of Online Accounts of course; it's always been
> > designed as part of the system, that's used by the system and the core
> > apps. Might take a little thought.
>
> We had a key store for web services API keys in Moblin/MeeGo, as part of
> libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
> keys, and OEMs didn't want to make their key public either. :-)
>
> Re-implementing that would not be hard, especially if we make it a
> prerequisite that new services must come with their own key. Additionally,
> it would let downstream vendors ship their own keys, if they are so
> inclined.

I don't understand.

Say, we had a GNOME API key for Google and another for application
Foo.  For all intents and purposes, those would need to be presented
separately to the user. The user would have to sign in separately to
GNOME and Foo and grant permission to each key, and so on. That's just
how the services work.

It's already feasible for a downstream to replace all the default
GNOME upstream keys shipped with GOA with their own using the build
flags. For example, Fedora could do that, as long as they are careful
enough to configure their keys properly.

What isn't possible is to mix and match API keys with account types at
run-time. That doesn't seem trivial to implement - neither from a code
nor a design perspective. Possible, sure; trivial, no.