Subject: Where do we validate surface attributes?

From: [email-masked]
Date: Tue, 30 Jun 2015 16:39:10 +1000

Hey all,

In response to Alan's comment¹ and my follow-up² I'd like to bring up 
a design question: do we validate surface states before handing them 
off to the shell, and if so, where?

Previously we ensured that client couldn't create invalid surfaces - a 
menu without a parent, a normal surface with a parent, etc - by making 
impossible to express such surfaces through the client API.

We've abandoned that approach, as it was starting to impose significant 
costs for not a huge gain, and now clients can create whatever 
MirSurfaceSpec they desire.

I think we should still do that validation before handing off to the 
shell. My understanding is that AbstractShell::WindowManager is 
expected to be Shell code, so this would be a filter between 
FrontendShell and AbstractShell?

What do others think? Do we want to do the validation at all, or should 
we punt it to the shell?

¹: 
https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001/comments/656064
²: 
https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001/comments/658830

---

From: Cemil Azizoglu <[email-masked]>
Date: Tue, 30 Jun 2015 11:21:10 -0500

My understanding, after discussion during standup, is that the validation
of attributes should be left to the WM policy. Mir will have a default one,
but shells can override it if they so choose. Though this approach has some
shortcomings.

Of course, a shell can only diverge so much from the default policy. E.g.
implementing a VR shell without changing the client side semantics would
not be possible. So a new shell would still have to be bound by the
existing notions of what a Dialog, or a tooltip is. But within reasonable
limits, some tweaks to behavior can be made (everything fullscreen, etc).

Invalid combinations of attributes will generate errors and logged so
clients can figure out what they are doing wrong.

A problem I see is that this would require clients to be aware of which
shell they are running on so they generate attribute settings that conform
to that particular shell. That doesn't sounds like a good thing. An
application running perfectly on a particular shell may start getting
errors on a new shell. Not sure what we can do there. Anybody have ideas?

On Tue, Jun 30, 2015 at 1:39 AM, <[email-masked]> wrote:

> Hey all,
>
> In response to Alan's comment¹ and my follow-up² I'd like to bring up a
> design question: do we validate surface states before handing them off to
> the shell, and if so, where?
>
> shell. My understanding is that AbstractShell::WindowManager is expected to
> be Shell code, so this would be a filter between FrontendShell and
> AbstractShell?
>
> What do others think? Do we want to do the validation at all, or should we
> punt it to the shell?
>
> ¹:
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Alberto Aguirre <[email-masked]>
Date: Tue, 30 Jun 2015 12:36:42 -0500

I think we should avoid replicating validation rules when possible, because
in the end, validation is really up to the window manager policy - its the
one entity which knows the valid combination of parameters.
Translating from protobuf optional fields
to scene::SurfaceCreationParameters which use mir:::optional objects
already propagate the information about whether a client specified a
parameter or not so the policy has enough knowledge to validate
requests.

For our window management core policies - BasicWindowManager::add_surface
could have an explicit call to the policy, such as policy.validate(params)
so that it can fail surface_creation.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Wed, 01 Jul 2015 14:35:05 +1000

On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre 
<[email-masked]> wrote:
> I think we should avoid replicating validation rules when possible, 
> because in the end, validation is really up to the window manager 
> policy - its the one entity which knows the valid combination of 
> parameters.

I don't think this should be true, and it certainly *wasn't* true when 
we had a constrained client API.

There are certainly *some* attributes that are going to be 
shell-specific - window sizes, fullscreen placement, and so on - but I 
think there's a core that aren't. It doesn't make sense to make a menu 
surface without a parent, and so on.

Our client API isn't usable if we don't have defined semantics for 
various things - how does input interact with having a menu open? What 
happens if you make a menu with a menu as a parent? What happens if you 
close a menu?

For the benefit of both clients and shells it would be good if we 
implemented at least some of this in Mir. A correct shell will need to 
have this behaviour, and clients will need to be able to depend on this 
behaviour.

The semantic content of our API is not just there so that shells can do 
the right thing when a client creates a parented-dialog; it's also 
there so that clients can know what the right thing is.

---

From: Andreas Pokorny <[email-masked]>
Date: Wed, 1 Jul 2015 15:51:27 +0200

Hi,

On Tue, Jun 30, 2015 at 6:21 PM, Cemil Azizoglu <
[email-masked]> wrote:

> [...]
This sounds like a good motivation to put the validation inside
libmirclient, hence make it independent of the mirserver. We currently do
not intend to make the protocol itself easily extensible. So the the set of
things to do and configure by a client is limited by libmirclients API.
Just weakening the requirements of that fixed set of client requests does
not create playground for freely definable window management concepts. So I
believe that would end up being a bad compromise. So we should keep
libmirclient strict, and motivate anyone interested in extending those
concepts to simply extend libmirclient.

---

From: Kevin Gunn <[email-masked]>
Date: Wed, 1 Jul 2015 11:12:47 -0500

But one question about putting things in client side, can we always assume
that any policy we have can be isolated to a per client attempt to act on
surfaces ? in the instance you might want to have a broader view of the
entire scene being composed (other clients and their surfaces and states),
the server side would be better in that instance. Maybe that's overkill
since i can't think of a good example...

---

From: Alberto Aguirre <[email-masked]>
Date: Wed, 1 Jul 2015 13:45:27 -0500

On Tue, Jun 30, 2015 at 11:35 PM, Christopher James Halse Rogers <
[email-masked]> wrote:

> On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre <
> [email-masked]> wrote:
>
>> because in the end, validation is really up to the window manager policy -
>> its the one entity which knows the valid combination of parameters.
>>
>
> I don't think this should be true, and it certainly *wasn't* true when we
> had a constrained client API.
>
I guess I disagree. We have a core policy object that shells should reuse,
in which we can just centralize the validation of parameters.

>
> There are certainly *some* attributes that are going to be shell-specific
> - window sizes, fullscreen placement, and so on - but I think there's a
> core that aren't. It doesn't make sense to make a menu surface without a
> parent, and so on.
>

Yes, but I still think that core lives in the window manager policy that we
already have in mir, which shells should use.

>
> Our client API isn't usable if we don't have defined semantics for various
> things - how does input interact with having a menu open? What happens if
> you make a menu with a menu as a parent? What happens if you close a menu?
>
> implemented at least some of this in Mir. A correct shell will need to have
> this behaviour, and clients will need to be able to depend on this
> behaviour.
>

We do, that's the core window management policy that shells should use (and
indeed qtmir will use).

> the right thing when a client creates a parented-dialog; it's also there so
> that clients can know what the right thing is.
>
> Agreed, however, only up to a certain set of shell types (i.e. unity/gtk
like, 2D windowing thingies).  A completely different shell (say a VR
shell) may have completely different client semantics anyway - the question
is do we want to support such things?

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 02 Jul 2015 09:58:18 +0800

I agree with Alberto et al here.

Anything other than range and syntax checking in libmirclient is too 
much. Semantic checks must be done on the server because the definition 
of what is semantically correct varies between shells. An app should be 
written once, try to set everything it wants, send the request off and 
see if the server (shell) accepts it. To do semantic checking in 
libmirclient limits the number of shells your app will ever be able to 
run in.

In fact I don't think it's even a matter of failure -- I would like to 
see shells just always do a best effort and never fail to start an app. 
That's more like how X window managers work today. Your app won't fail 
to start, but it may not look best under all WMs. There, surface types 
and states are more of a hint than a rule. And IMHO that X approach is 
better because at least your app always starts. If it doesn't start then 
you may be stranded, unable to fix the app to run on your shiny new shell.

On 02/07/15 02:45, Alberto Aguirre wrote:
>
> On Tue, Jun 30, 2015 at 11:35 PM, Christopher James Halse Rogers
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         I think we should avoid replicating validation rules when
>         possible, because in the end, validation is really up to the
>         window manager policy - its the one entity which knows the valid
>         combination of parameters.
>
>
>     I don't think this should be true, and it certainly *wasn't* true
>     when we had a constrained client API.
>
> I guess I disagree. We have a core policy object that shells should
> reuse, in which we can just centralize the validation of parameters.
>
>
>     shell-specific - window sizes, fullscreen placement, and so on - but
>     I think there's a core that aren't. It doesn't make sense to make a
>     menu surface without a parent, and so on.
>
>
> Yes, but I still think that core lives in the window manager policy that
> we already have in mir, which shells should use.
>
>
>     various things - how does input interact with having a menu open?
>     What happens if you make a menu with a menu as a parent? What
>     happens if you close a menu?
>
>     implemented at least some of this in Mir. A correct shell will need
>     to have this behaviour, and clients will need to be able to depend
>     on this behaviour.
>
>
> We do, that's the core window management policy that shells should use
> (and indeed qtmir will use).
>
>
>     The semantic content of our API is not just there so that shells can
>     do the right thing when a client creates a parented-dialog; it's
>     also there so that clients can know what the right thing is.
>
> shell) may have completely different client semantics anyway - the
> question is do we want to support such things?
>
>
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 02 Jul 2015 15:18:29 +1000

On Thu, Jul 2, 2015 at 4:45 AM, Alberto Aguirre 
<[email-masked]> wrote:
> <[email-masked]> wrote:
> Yes, but I still think that core lives in the window manager policy 
> that we already have in mir, which shells should use.
> 
>> 
> We do, that's the core window management policy that shells should 
> use (and indeed qtmir will use).

I guess this is what I'm getting at: we've got a component that we 
expect shells to use, and that shells which *don't* use it will need to 
reimplement or break our client API. Why would we let a shell override 
this in the first place?

Hm. Maybe we're actually agreeing? We'll have this validation layer in 
the core WM code, before the code that we expect shells to override?

> Agreed, however, only up to a certain set of shell types (i.e. 
> unity/gtk like, 2D windowing thingies).  A completely different shell 
> (say a VR shell) may have completely different client semantics 
> anyway - the question is do we want to support such things?

We can't. Or, rather, supporting them requires new client API anyway. 
If they have different semantics then they have a different API, even 
if that API uses functions with the same name.

The client API isn't just the set of C-linkage entrypoints. The 
semantics are a part of the API.