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. > 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. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
