Code review comment for lp:~alan-griffiths/mir/first-pass-of-surface-spec-modification

So, I'm okay with this approach, as opposed to some sort of "lock" guarantee, as that seems to raise all sorts of questions about what a 'locked' surface might mean.
The wait handle seemed useless too, so also okay with its removal.

Chris's point that the nested stuff (or other clients) can maintain some of their own info is a good one. I'm not sure though that we explain well what changing a surface spec means... It makes sense to me to say that "when the title name is set to "X" on the MirSurfaceSpec, it will be presented as "X" when the server chooses to show a title", as opposed to saying "when the title name is set to "X" on the MirSurfaceSpec, it can be silently rejected"

needs-info:
1) Shouldn't this take a MirSurfaceSpec* instead of of a MirSurface*?
31 +void mir_surface_set_title(MirSurface* surface, char const* name);

2) Is it (or will it be) possible to construct a MirSurfaceSpec that's invalid? For instance, if we have a mir_surface_spec_set_size(..., int x, int y), and someone tries to morph a tooltip to a tooltip that spans multiple monitors that seems to violate the meaning of the types in the spec document. It might make sense to indicate to the client that its request was "flat-out rejected forever", instead of "accepted as something that the server will try to apply when appropriate".