<div dir="ltr"><div><div class="gmail_quote">All your objections sounds like you are confusing the implementation with the abstraction that the client program sees. A few examples:<br><br>On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Yes this also creates<br>
> multiple C structures in the server, to keep track of the actual client<br>
> communication, but for most documentation you act as though there is one<br>
> "object" that all the clients are "sharing".<br>
<br>
</span>Please point out that document so it can be burned to the ground and/or fixed.<br></blockquote><div><br></div><div>Description of wl_output:<br><br>      This object is published as global during start up, or when a monitor is hotplugged.<br></div><div><br></div><div>That certainly implies there is one wl_output per monitor. Not one per monitor * client. You seem to be thinking about how many "publishing" events have been sent by the compositor to all the clients, or perhaps how many wl_proxy objects have been created by clients for wl_outputs, but that is not a number that anybody, including the person who wrote the above documentation, is thinking about. The programmer thinks there is a wl_output for each physical monitor, and that since the client program cannot destroy or create monitors, and monitors continue to exist when all the clients exit, that there is a single shared wl_output object.<br><br></div><div>Also your claim that state is not "shared" is false. Every client will get matching geometry events for a given wl_output (or if you insist, it will "get a matching geometry event for each wl_proxy that they created using the global id that the server advertised for it's internal data structure that represents the state that a wl_output created by the client for that id will see").<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>It is totally possible for the client to destroy global objects: send,<br>
e.g., wl_compositor_destroy(). Great, object gone.<br></blockquote><div><br></div><div>Another client (or even the same one) is certainly able to assocate an objectId with the state inside the server that every sensible programmer in the world will call "the wl_compositor". It is not destroyed in any way!<br><br><br>In any case I would like to see 
if the idea of nested compositors will work since that seems to be your 
goal. However it looks like a nightmare of complexity and confusion for 
programmers. How exactly do you plan to send every type of buffer with 
zero copy through the intermediate client? Does the client have to know 
about every single type of memory sharing, or will the subclients be 
prevented from taking advantage of server capabilities because the 
intermediate clients are too old? What about the overhead of virtually 
every message having to be decoded and recoded by the intermediate 
client in both directions? What about messages that need an xdg_surface (such as the parent surface) that the child did not create?<br><br></div></div></div></div>