Client API philosophy

[Christopher James Halse Rogers]

On Tue, Nov 11, 2014 at 12:33 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> 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).

Equally, we must enforce policy via client function prototype. 
Otherwise you can't write a client and expect it to work against any 
sane shell.

Functionally, in the best case¹, this will end up with is an 
out-of-tree specification of window management semantics that clients 
and shells are expected to adhere to.

¹: If Mir is actually used by things other than Unity 8. If Mir 
remains just Unity 8's toolkit then Unity 8's behaviour is obviously 
the specification of Mir window management.

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

Right, but we want more than strong enforcement of policy. We want to 
be able to write clients that work against any sane shell. If the 
client API doesn't specify what behaviour a client can expect a sane 
shell to have in response to a given API call then that API call can't 
be used by sane clients.