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.v...@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.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
