Hi Jason, thanks for working on this, it does seem very useful, practically a mandatory feature to support.
<Thinking out loud> We already had the versioning rules documented, right? Whenever bumping an interface version, also the parent interface (factory) version must be bumped. That makes the version inference you implemented work. It also means that an interface may at runtime get a version number bigger than what the protocol spec has ever defined. Oh but it also goes the other way. Let's say interface A has methods to create objects with interfaces B and C. Let A.ver = 1, B.ver = 1, and C.ver = 1 in the specification. Bump B: A.ver = 2, B.ver = 2, C.ver = 1 Bump B: A.ver = 3, B.ver = 3, C.ver = 1 Bump C: A.ver = 4, B.ver = 3, C.ver = x Now, wl_proxy_get_version() for objects of type B and C always returns the version of A, essentially. Therefore, to properly handle the bump of C, we must have x=4. That is, when a child interface version is bumped, it must be set to the parent's new version, not just incremented by one. If x=2, then if A.ver was 2 or 3, it would falsely claim that C has the new feature that was added in the C bump. Oh yeah, we do have it documented in http://wayland.freedesktop.org/docs/html/sect-Protocol-Versioning.html Seems to work, and I suppose the existing revisions in protocols in wayland and weston follow these rules already? </out loud> 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? But I guess it would still be broken on any other request that used the interfaceless format of new_id? > 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. Thanks, pq > --Jason Ekstrand > On Apr 2, 2014 12:28 AM, "Jason Ekstrand" <[email protected]> wrote: > > > This provides a standardized mechanism for tracking protocol object > > versions in client code. The wl_display object is created with version 1. > > Every time an object is created from within wl_registry_bind, it gets the > > bound version. Every other time an object is created, it simply inherits > > it's version from the parent object that created it. > > > > > > --- > > I've been meaning to scratch this itch for a while. I've left it as an RFC > > for now because it builds, but I don't have any code to test it yet. I've > > got something I'm hoping to hack on this weekend that will use it. For > > now, feel free to comment. > > > > src/scanner.c | 29 +++++++++---- > > src/wayland-client.c | 112 > > +++++++++++++++++++++++++++++++++++++++++++++++---- > > src/wayland-client.h | 13 ++++++ > > 3 files changed, 139 insertions(+), 15 deletions(-) _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
