Client API philosophy

[Daniel van Vugt]

I've already explained why that is untrue. Twice.


On 11/11/14 10:03, Christopher James Halse Rogers wrote:
>
>
> 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.
>
>