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).
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.
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643732
Title:
service() method returns invalid service instance
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/online-accounts-api/+bug/1643732/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
