<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - protocol xml: align interface version number with it's factory counterpart" href="https://bugs.freedesktop.org/show_bug.cgi?id=82126#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - protocol xml: align interface version number with it's factory counterpart" href="https://bugs.freedesktop.org/show_bug.cgi?id=82126">bug 82126</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to <a href="show_bug.cgi?id=82126#c1">comment #1</a>) > 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 <a href="show_bug.cgi?id=82126#c2">comment #2</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>