Where do we validate surface attributes?

[Alberto Aguirre]

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.






On Tue, Jun 30, 2015 at 1:39 AM, <raof at ubuntu.com> 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?
>
> 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
>
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150630/609ef6ff/attachment.html>