<div dir="ltr">On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not clear on why Wayland's design requires adding 2 dummy objects to the api (in this case the "wl_scalar" factory and the per-surface "wl_surface_scalar") rather than just adding new methods to the wl_surface object.<br>


<br>
It seems wasteful for clients and servers to track this whole constellations of id's for the same wl_surface. It also looks too much like X where I had to keep the window, visual, visual id, screen, colormap, gc, and I forget what else, because all the X functions required different arguments types for no discernible reason when they could all be derived from the window id.<br>


<br>
I'm guessing there is a good reason for compatibility but it seems that just adding more message numbers after the already-used ones would work. To avoid collisions between multiple extensions the server could instead send an event saying "the scalar messages to wl_surface start at N" and this single number, rather than an per-surface extra object id, is all the client needs to remember.<br>

</blockquote><div><br></div></div><div>I agree that keeping piles of extra objects around may not be the best solution.  However, we cannot simply have "the scaler messages to wl_surface start at N" type message.  This would require substantially altering the wire protocol along with libwayland.</div>
</div></div></div></blockquote><div>I think adding that would be mostly additions to libwayland/wayland-scanner and wouldn't require modifying the wire protocol at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Even if we did make those changes, I think we would end up right back where we are now having to manage extension proxies so we wouldn't save anything.</div>
</div></div></div></blockquote><div>We would only have to manage an extension object per connection client-side and only one object for all connections server-side, which would be a huge improvement over the current state.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Besides, I'm pretty sure one of Kristian's main ideas in the core wayland protocol is "everything's an extension" so this IS the extension system.</div>
</div></div></div></blockquote><div>It's more like you can add new object types which may or may not be extensions of others, not so much an extension system as a way of doing extensions.</div><div><br></div><div>We should probably split off any plots for libwayland changes elsewhere...</div>
<div><br></div><div> </div><br></div>