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
