On 30/11/2016 14:49, James Henstridge wrote:
> For what it is worth, I think there is value in keeping the blank/no app
> ID mode working for the benefit of trusted helpers that need to work on
> behalf of a number of confined processes using different AppArmor
> labels.  You could special case storage-framework, but I doubt we'll be
> the last to want this sort of access (heck, we're one of the first
> pieces of code using this new API).

Your use-case is a bit on the edge, but AFAIU it should be supported. A
service that authenticates on behalf of other apps should instantiate an
AccountManager for each app, specifying the app's ID, and this should
just work.
However, your case is a bit different, in that -- I believe -- you don't
want the client apps to have any knowledge of online accounts (you
handle it transparently for them) and you handle the app permissions
yourself. The fact that the user has to go through the Online Accounts
trusted prompt in order to authorise the storage-framework to use a
certain account is probably more an annoyance than a desired experience.
In practice, you are not simply acting as a bridge between the client
apps and OA, but you are actively shielding these parts from knowing
about each other: the apps won't see anything from OA, and OA won't see
anything from the app. That's fine, but since OA needs to know about its
client, it follows that storage-framework needs to identify itself. Once
you do that, then we can even special-case it and change the UI flow
just for you, if that's needed.

> Given that everything else in the API works with a blank app ID, I would
> tend to see the fact that this doesn't work as a bug rather than a
> result of undefined behaviour.

Not really: between adding complexity to the code of the OA service and
you adding an XML file to your project (which you'll need to add anyway,
to get our trust prompt working properly), I'm not scratching my head to
decide which one is better. :-)

> And looking at the D-Bus API, this still seems like a weird way to
> package up the information we need.  At the moment, there are 3 ways to
> receive information about accounts:
> 
>  1. all accounts from the GetAccounts method.
>  2. a changed account from the AccountChanged signal
>  3. one account from RequestAccess method.
> 
> As it is now, the service information is only returned by GetAccounts,
> with no information being returned if an app ID hasn't been supplied.
> Given that AccountInfo already included an a{sv} dictionary, stashing
> the information there seems like a simpler solution.  It would have
> ensured the information was available whichever way the client learned
> about the account, and it would piggyback on the filtering already
> performed on the account list.

That's another issue, please let's discuss it separately. But just briefly:
* You might have just providers, with no accounts created
* The client lib starts by calling GetAccounts (and any alternative
implementation should do the same), so the info is already all there; no
need to resend it again later.

It's not settled on stone, we might have to add a ProvidersChanged
signal for when new providers are installed, but that's another issue again.