On Wed, Oct 21, 2015 at 12:21 PM, <r...@ubuntu.com> wrote: > On Tue, Oct 20, 2015 at 11:16 PM, Gerry Boland <gerry.bol...@canonical.com> > wrote: >> >> Hey folks, >> it appears this topic has gone stale, without any consensus being reached. >> A core issue impacting this discussion which remains undecided is the >> following: >> >> - Is it in Mir's scope as a display server to provide a client api for >> configuring mir server settings like those for displays & input devices? Or >> should Mir expose a mirserver API for these settings, and require the shell >> to implement its own API via an alternative channel (e.g. DBus) for a >> settings client to use? > > > I have a well-known aversion to shipping API that is useful for exactly one > client which is always shipped with the shell and is harmful if used by any > other client. Both the set-base-display-config and set-input-configuration > APIs fall under this concern. >
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. > Now, that said, this *is* something that every shell is going to need to > handle in some fashion, and it's perfectly reasonable for Mir to provide > support for it. In the Wayland world this is just done with ad-hoc protocol, > because that's easy. For us, I think that having a separate > libmirclient-shell¹ that contained these APIs would satisfy my paranoia and > also be useful for Unity8. > > For bonus fun points this will be another capability check needed on the > MirConnection. Can we add a create_privileged_session_for(socket) API, or is > it still not possible for Unity8 to hand sockets off to clients? > 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. > ¹: Name to be exhaustively bikeshedded. > > > > -- > 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
