On Wed, Oct 21, 2015 at 4:38 PM, Alan Griffiths <alan.griffi...@canonical.com> wrote: > On 21/10/15 11:38, Thomas Voß wrote: >> Well, we always need to satisfy the case of handing configuration up & down a >> nested shell scene. If we don't add the respective functionality to >> the client api, we end up in >> the situation of Unity8 being unable to speak to its parent Mir >> instance. With that, configuration API >> should live in the client API from my POV. > > I'm not sure what /you/ are referring to here. The existing APIs and > design deals with handing configuration up & down a nested > configuration. The discussion is about adding an API to change the > Unity8 "base configuration" - the one used when the current client (if > any) hasn't selected a configuration itself.
Hmmm, I fail to see the difference, even having re-read the thread. Would you mind summarizing where the difference arises? >> Either that, or we borrow ideas from Macaroons, requiring clients to >> pass in a "cookie" to privileged functions. >> One additional benefit would be easier reading of the API as the >> arguments make it immediately clear which functions require a prior >> negotiation of permissions. > > We could do the same as we have with prompt providers and simply connect > the configuration client via a "trusted" socket. > Well, the prompt provider solution was introduced as a first step towards a more generic mechanism for handling "privileged" API. I'm not saying we have to come up with a full-featured solution right now, but we should keep in mind that a "trusted" socket only allows for very coarse-grained authentication of clients. Cheers, T > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
