Client API philosophy

[Daniel van Vugt]

We are actually in violent agreement on "policy" and conflating two 
different issues. So please, let's separate them :)

It is indeed up to the server/shell to dictate policy, particularly as 
it can and will vary between shells/modes of a shell. Anything invalid 
is returned as an error to the client API, or in the form of a 
non-blocking API:

   1. asynchronous set feature A = B
   2. optional wait and get feature A, and check it was changed to B or 
something else dictated by shell policy.

What we must not do is try to enforce policy via client function 
prototype design. Because policy changes not just between shells, but 
even between modes of a shell (e.g. we aim to unify Unity8 desktop with 
touch I think).

The confusion here is coming from some people thinking that a flexible 
API prevents strong enforcement of policy. It does not.

P.S. "menus" are explicitly not a window type right now (as copied from 
the WM design docs). So it's possibly assuming too much to mention the 
the word "menu" in the client API. Although we possibly could - rename 
popover?


On 10/11/14 17:58, Alan Griffiths wrote:
> On 10/11/14 03:31, Daniel van Vugt wrote:
>>
>> Sounds like a response to one of my merge proposals. So please put
>> arguments in the code reviews...
>
> There's a good reason to discuss this outside of a specific code review:
> we need to agree the "big picture".
>
> There is an apparent disagreement about the approach to window
> management policy and that affects the review of any and all MPs in this
> area.
>
> I've always understood the intent to be that Mir enables shells (in
> general and specifically unity8) to implement policies about how things
> should be presented. It is far easier for a shell to provide a policy
> around, say "menus" if it is asked to "show a menu" than if it is asked
> for a window, then asked to "parent" it, then asked to position it, etc.
> With this approach there is never any point at which the server knows
> what the client intends.
>
> If we intend to push the presentation policy out to the client toolkits
> then they will provide inconsistent (a.k.a. incorrect) policy
> implementations. (Especially if, as we should hope, there are multiple
> shells written using the Mir library that implement policies differently.)
>
>
>