Code review comment for lp:~vanvugt/mir/parenting-client-api

> +1 for a semantics-based API as opposed to a state-based one. I wouldn't want
> to have to use an API where there are hundreds of states to choose from and a
> small subset of each has some special meaning (a menu, a tooltip, a dialog,
> etc) and other combinations are not even valid - giving too much flexibility
> to the user to shoot themselves in the foot.
>
> I'd like to be able to just call one function to create, say, a menu. Simple
> enough for the user to get started using our API, simple enough for us to
> manage. Of course, as the need arises, we can later break down the API and
> provide finer level of control as is being proposed here. We can do this on a
> case-by-case basis as we gain some insight into what users want to achieve and
> where it makes sense to have more flexibility. It's easy, and backwards-
> compatible, to do that. However, it's not easy to take it back cf. server ABI.
>
> So IMO the API that is being proposed here is rather the implementation and
> could/should stay as an internal API, which could then be made public, with
> some extra state validation, if needed.

If we have such an "internal API" in the client code I think we lose any benefit of having a "semantics-based API". The value I can see from in the latter approach would come from passing the semantic information "this is a menu" to the server so that the shell can implement policies to control any fine grained state.