Enums, bitfields and wl_arrays in the .xml file

Victor Berger victor.berger at polytechnique.org
Thu Sep 24 04:00:38 PDT 2015


Hi,

After some discussions on IRC, it appears this raises several concerns 
about back-compatibility.

The main points being:

- if a protocol file previously did not use these extra attributes, and 
choses to add them, depending on the language using them it can be a 
breaking change (as it would change the prototype of the requests from 
u(int) to the enum type for example)
- if a variant is added to an already existing enum, it can be a 
breaking change for some languages (Rust is one of them, as the compiler 
enforces you to cover all possible variants when matching on an enum).
- some enums, like xdg_shell::xdg_surface::states are by definition not 
complete.
- and most likely other similar issues with "array" types or so

These questions need to be resolved, and a proper specification of what 
should contain the .xml files will certainly need to be written to 
properly handle all this.

To other bindings writers: what are you opinions and constraints on 
these back-compatibility hazards ?

In my case (Rust):
- the question adding the an "enum" attribute to a field that didn't use 
it is a breaking change that needs thought.
- adding a variant to a bitfield is not a problem
- adding a variant to a classic enum is not trivial a priori, but I have 
possibilities to future-proof this with small overhead, and it would 
handle incomplete enums as well. (it involves using a wrapping struct 
that optionnaly tries to convert the raw value to the enum)
- as well, adding the specification of the type contained in an array to 
an arg that didn't have it would be a breaking change, and as such needs 
thought.

----
Victor

Le 2015-09-18 20:55, Bill Spitzak a écrit :
> On Fri, Sep 18, 2015 at 5:37 AM, Nils Chr. Brause
> <nilschrbrause at gmail.com> wrote:
> 
>> Hi,
>> 
>> There are even earlier discussions about including 'bitfield' and
>> 'enum' fields into the XML protocol file, e.g:
>> 
> http://lists.freedesktop.org/archives/wayland-devel/2014-September/017071.html
>> [1]
>> But none of them led to any actual changes.
>> 
>> I still would very much like to see the 'bitfield' and 'enum'
>> fields
>> to be included in the XML protocol file. This would greatly
>> simplify
>> the creation of Wayland bindings for most high level programming
>> languages and thus increase the popularity of Wayland amongst
>> programmers who don't wish to use toolkits.
>> Without these information about bitfields and enumerations,
>> language
>> bindings would have to maintain their own version of the XML
>> protocol
>> file, like I am doing with my C++ bindings here:
>> https://github.com/NilsBrause/waylandpp [2]
> 
> Yes please get this in. I really expected this to be merged long ago.
> 
> This is almost a requirement for bindings for any language other than
> C. And it greatly improves the automatically generated documentation
> of the C api, too!
> 
> And it is absolutely 100% compatible with everything that exists right
> now (except code reading the xml files, which might have to be
> modified to ignore the new tags). It does not change the size or bit
> layout of any data in the stream protocol and does not change the C
> api, and does not prevent the sending or construction of any message
> or event that can be sent right now. In particular it does not prevent
> bit patterns that are not in the enumeration from being sent by the C
> api.
> 
> 
> 
> Links:
> ------
> [1]
> http://lists.freedesktop.org/archives/wayland-devel/2014-September/017071.html
> [2] https://github.com/NilsBrause/waylandpp
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



More information about the wayland-devel mailing list