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

As for the API changes, I'm all for publishing some sort of surface-changing functions (with a slightly different way proposed in the rfc-branch https://code.launchpad.net/~kdub/mir/RFC-surface-arrangements/+merge/254982)

My points here:
After I call mir_surface_create(), the MirSurfaceSpec seems to be associated with the surface. It makes more sense (to me at least) to query the surface, where MirSurfaceSpec "lives", for the existing specification of the surface.

This also leads to the topic of guaranteeing that the surface is in a particular state while the client decides what to do with the surface next. Like, it seems sensible that we have to lock the surface state, and then apply all the changes at once, and then 'unlock' the surface for further server-started changes.

It also seems that just rejecting change-specs the server doesn't like will lead to a somewhat frustrating back-and-forth for the clients trying to apply the change they want and then being told for non-obvious reasons that the change that was requested was rejected.