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)

But isn't that now about arranging buffer streams within a surface, and not to do with modifying the surface.

> 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.

I don't think the MirSurfaceSpec is associated with a surface. If I were to call mir_surface_create() three times and get three surfaces would you consider it associated with all of them?

> 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.

Clients cannot reasonably "lock" the state of the surface - the window manager needs to respond to user input, display changes etc.

> 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.

There is no way for a client to get a meaningful response to a change spec request. It is "fire and forget". There will likely be corresponding events from the server - but even if the request is honored in full the surface may never be in the requested state because of concurrent changes by (e.g.) the user.