Currently the xml defines factory interfaces with a version. Implicitly the created object's interface should have the same version as the factory. However the protocol xml does not align factory interface versions with the interfaces of objects it creates. This leads to confusing and cumbersome parsing because implicit rules and restrictions have to be deduced from the protocol xml when generating bindings. Example (1.5): wl_compositor can be v3, has a create_region with new_id. wl_region can be at most v1. My suggestion is to align interface versions so that they match the interface version of the factory that creates it.
wl_compositor gets v3 because wl_surface is v3. The documentation says "When the version of an interface increases, so does the version of its parent", the children not affected by the change won't be bumped. If children version got bumped, then nearly the whole protocol would bump version just because a little change somewhere, which can be quite insane.
Ok that makes sense I guess. So the rule is to implicitly always create an object with the latest available interface version defined in the xml? That's doable I guess, although it makes parsing the protocol a pita as you have to keep and update state over the entire protocol when parsing the xml tree. :(
(In reply to comment #1) > wl_compositor gets v3 because wl_surface is v3. > > The documentation says "When the version of an interface increases, so does > the version of its parent", the children not affected by the change won't be > bumped. If children version got bumped, then nearly the whole protocol would > bump version just because a little change somewhere, which can be quite > insane. Not almost the whole protocol, just everything under a single global interface in the hierarchy, which should be a tree. The hierarchy is defined by what interface (factory, parent) can create objects of another interface (child). All new protocols must have the hierarchy as a tree, but the core protocol has wl_callback, which can be created via more than one unrelated interfaces, and that is a problem we cannot fix. But yeah, there would be some churn and room for human errors, if we required all interfaces in a hierarchy to bump version at the same time. (In reply to comment #2) > Ok that makes sense I guess. > > So the rule is to implicitly always create an object with the latest > available interface version defined in the xml? That's doable I guess, > although it makes parsing the protocol a pita as you have to keep and update > state over the entire protocol when parsing the xml tree. :( I'm not sure I understand what you are saying. At code generation time, you would need to scan the interface hierarchy of each interface up to the root (global), and use the root's version for inferring what version numbers are valid at runtime for any child interfaces. Then in each interface, you can pretty much ignore the version defined in the XML, and just look at the 'since' attributes to get the valid version ranges for each message. That is, if you even need any concept of a "maximum version". The 'since' attributes say, that this message is available in versions this and all greater ones. So looks like the version declared in the heading of the interface in the XML is pretty useless except for validating the XML, and for globals.
Ok, I think I can work with the current situation :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.