On Thu, 10 Apr 2014 09:42:55 -0500 Jason Ekstrand <[email protected]> wrote:
> On Thu, Apr 10, 2014 at 6:37 AM, Pekka Paalanen <[email protected]> wrote: > > > Hi Jason, > > > > thanks for working on this, it does seem very useful, practically a > > mandatory feature to support. > > > > Hi Pekka, > Yeah, I've been itching to knock this out for a while. Just finally got > around to it. Comments below. ... > > On Wed, 2 Apr 2014 09:48:29 -0500 > > Jason Ekstrand <[email protected]> wrote: > > > > > It's worth noting that there is one small backwards-compatability issue > > > here. Namely, if the client is built against protocol stubs from an > > > earlier version of libwayland but links against a library built against a > > > newer version, then all objects created by the client will report a > > version > > > of 1. This is because the old api uses wl_proxy_marshal_constructor in > > > wl_registry_bind so all objects will inherit the protocol version of > > > wl_display which is 1. The library the client linked against is aware of > > > the wl_proxy_version function but has no way of knowing that the library > > > does not. > > > > I was about to say that wl_registry_bind() does pass the version to > > wl_proxy_marshal_constructor, but that indeed is in the request > > arguments and not a mandatory argument. > > > > But wl_proxy_marshal_constructor() would still have all the information > > it needs, if we special-case wl_registry.bind inside it. Ugly, but I > > guess it'd work for wl_registry. Would that make the > > backward-compatibility issue go away? In all other cases you would take > > the version from the parent wl_proxy, which you always have available > > in wl_proxy_marshal_constructor(), and the versioned variant would not > > be needed? > > > > Yes, we could do that, and I considered it. However, it would only bump > the compatibility issue back to wl_proxy_marshal_constructor. Older code > that uses wl_proxy_create inside of wl_registry_bind is still in trouble. > I don't think it's a huge savings to just bump the compatibility issues > back to 1.3 rather than 1.4/1.5. In the long run, I don't think it's worth > the mess that we would create inside wl_proxy_marshal_constructor. Ok, I didn't even know to think that far back. Makes sense. > > But I guess it would still be broken on any other request that used the > > interfaceless format of new_id? > > > > Nope, that's not a problem. The wayland-scanner program doesn't actually > special case wl_registry_bind but interfaceless new_id's in general. > Anything else that specifies a new_id with no interface will hit the same > code-path and get wl_proxy_marshal_constructor_versioned. I meant if we special-case wl_registry.bind, then all other requests using interfaceless new_ids would still be in trouble. But yes, a moot point now. > > > One possible solution for this is to set the version of wl_display to > > zero > > > and use zero to mean "unversioned". Then, if a library wants to use > > > something that's not strictly backwards-compatable, it can check for zero > > > and use whatever it's non-versioned fallback is. > > > > Thoughts on this? ^^ Well... if you don't know the version, is there a difference between assuming it is 1, and knowning it is unknown and then assuming whatever? As I see it, the only benefit of knowing when you don't know, is that you could then explicitly assume a higher version than 1, and then die on a protocol error if you are wrong. I'm not sure if that is better than assuming 1 which will always work if the application only accepts that. It looks like a trade-off between an "unknown method" protocol error / events that never come, and the application complaining the server is too old, when things go wrong. I can't say. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
