Client display configuration notification

[Christopher James Halse Rogers]

On Thu, Oct 22, 2015 at 5:15 AM, Thomas Voß 
<thomas.voss at canonical.com> wrote:
> On Wed, Oct 21, 2015 at 4:38 PM, Alan Griffiths
> <alan.griffiths at 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?

The “base configuration” is the shell's default configuration, 
applied when no client-specific configuration is applied.

At the interface between layers (kms ← USC or USC ← Unity8) there 
is no concept of “default configuration” - USC *has* to set *some* 
KMS configuration, and likewise, Unity8 has to set *some* configuration 
on USC.

The default configuration lives entirely inside a single layer; it only 
has influence on what configuration is requested of the lower layer.

>>>  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.

I'm rather partial to the capsicum method of delegating capabilities - 
if you've got a thing, you can use the thing.

In this case you could quite easily have a get_capability() RPC call 
that returns a socket you can talk that privileged protocol over. This 
also has the pleasant property of easily allowing us to split the 
client library into various bits - mirclient for all the API that 
regular clients need, mirclient-prompt for clients that need the prompt 
API, mirclient-testing for test-only APIs¹, mirclient-shell, and so on.

¹: This also lets us resolve a longstanding TODO in libmirclient-debug