Enums, bitfields and wl_arrays in the .xml file

Nils Chr. Brause nilschrbrause at gmail.com
Fri Sep 25 03:25:51 PDT 2015


On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
<victor.berger at polytechnique.org> wrote:
> What I meant here is that the format and contents of the XML files is
> currently defined by the implementation of the C scanner, which is a less
> than optimal situation to discuss evolutions of this format.
> There will most likely be a need to write a proper document describing the
> format of the XML files, as well as the semantic meanings of each field and
> attribute it contains.

Isn't the DTD file the specification for the XML file format?

> The questions about how breaking evolutions will be handled need to be
> specified as well: how should an old scanner behave when it encounters a
> more recent protocol file, containing fields or attributes it does not
> recognize ? Ignore them ? Fail and declare being "not compatible with this
> protocol format, please upgrade" ?

The last one makes the most sense to me. Someone who develops a
language binding should always keep her/his scanner up to date with the
most recent XML file format.

> I don't think other bindings than the C-scanner already have so many uses
> that they can't afford a breaking change (correct me if I'm wrong), so this
> is most likely the ideal time to properly specify the protocol file format
> in a way that contains all information required for a proper type-safety as
> needed by more high-level languages than C.
> [...]
> Future changes to the XML format would likely not be as painless, when
> various languages bindings will have many downstream users. Thus it is
> important to get a good version of the XML specification now. As there are
> bindings projects for various languages (at least C++, Java, Rust and
> Haskell that I am aware of), we can probably together reach a state handling
> (almost ?) all needs of type-safety.

I agree. The earlier these important changes are being made, the easier it is.

> I am aware this is a more consequent work than simply patching the xml
> files on the go as the need is encountered, but providing a good and complete
> proposition will most likely be better received by the wayland devs and the
> downstream users than just "breaking things as we need it".

Also, from the discussion last year it emerged that the scanner should also be
modified to at least check for the validity of the new attribues.
You can find the work that I had done so far here:


More information about the wayland-devel mailing list