State of Wayland protocol development

[Peter Hutterer]

On Fri, Oct 09, 2015 at 02:41:31PM +0800, Jonas Ådahl wrote:
> Hi again,
> 
> I implemented one of the brought up ideas to see how it'd work.
> More specifically, I created a repository called "wayland-protocols"[0]
> and adapted weston[1] to use it for the fullscreen shell. I also added 
> pointer gestures to make it obvious that its not only protocols that are
> implemented in weston that are part of it.
> 
> The way I imagine it would work is, for new protocols to be introduced,
> it'd have to be a agreed upon "correct" path (i.e. probably not
> wl_absolute_coordinates etc), which should simply mean that such a
> protocol should have been at least Acked-by one or more core developer
> that have acknowledged that it is a suitable thing to do in the Wayland
> ecosystem.
> 
> Protocol changes (including introduction) would also require
> Reviewed-by's by someone with enough knowledge*, and if a protocol has a
> maintainer(s), at least Acked-by one of them.
> 
> Releases of this repository would not be tied to releases of
> wayland/weston, and it wouldn't be a requirement to have a protocol
> implemented in weston to make it part of a wayland-protocols release.
> 
> Fast paced protocol development would be done on topic branches, and
> wouldn't be part of any release until properly reviewed. External
> projects would be encouraged to not release software releases that
> exposes such intermediate versions; if expected to use a common
> namespace, they should use a version from a wayland-protocols release.
> 
> Declaring a protocol stable could either be done by doing the renaming
> and moving it to wayland, or we could just move it to a stable/
> subdirectory in the same repository. I actually think this might be a
> better idea, so that we don't tie down protocol development to the
> reference compositor release cycle.
> 
> Patch merging could be done in the same way as with wayland/weston,
> assuming the patch merger makes sure the right persons have acked or
> reviewed.
> 
> Release management could either be done by the wayland/weston release
> manager or someone else. I could volunteer doing this if no one else has
> a strong urge.
> 
> For the more practical parts, the protocols in the repo now have
> versions in the XML file names and in the protocol element attribute, but
> not in the interface names. Having version numbers in the interface names
> would enable us to implement multiple versions in clients and servers,
> but it'd mean that each interface would have both a _ prefix and a
> version number. Maybe thats fine, and I wouldn't object if someone thought
> that would be better. It'd get rid of the redefinition of interface
> versioning for unstable protocols.
> 
> I still have the '_' prefix which, mentioned by Pekka, violates some
> rule in C. I'm not sure we need to care (we've been doing this in weston
> since 2013), but if anyone has a better suggestion or objection please
> say so.

just fwiw, in the C99 specs:
7.1.3 Reserved identifiers

- All identifiers that begin with an underscore and either an uppercase
  letter or another underscore are always reserved for any use.
- All identifiers that begin with an underscore are always reserved for use
  as identifiers with file scope in both the ordinary and tag name spaces.

so underscore + lowercase is generally fine, double underscore is definitely
a problem. as Daniel mentioned in some other email, newest g++ gets unhappy
quickly here.

> FWIW, the way things are structured in the repo now, it is possible (and
> enabled) to install unstable XML files. Copying would work as well. All
> these these minor practical details I don't have a strong opinion on,
> and I'd be happy change them if needed.
> 
> If we want to take this path with a protocol repository, after agreeing
> upon the details, I'd continue with moving away the generic protocols
> from weston, applying some "unstable protocol" rule regarding xml,
> protocol and interface names, and change weston to start using files
> from wayland-protocol (copied or installed).
> 
> Thoughts?
 
I like this approach, so count that as my +1, with the version number in
the name + a final rename when declared stable to make sure everything
breaks once more :)

one remaining question I have though: what are we to do with changes to the
wayland protocol itself, e.g. the pointer axis changes. There are a few that
cannot be easily added as separate interface, do we bite the bullet there
and merge it into the wayland protocol directly? or can we figure out some
overlay protocol where we override the official?

Cheers,
   Peter


> * How to determine this I guess is one of the things that needs to be
>   agreed upon, but I imagine it'd be different set of individuals
>   depending on the area the protocol touches.
> 
> [0] https://github.com/jadahl/wayland-protocols (only on github for
>     demonstration)
> [1] https://github.com/jadahl/weston/commit/caf37bb527740b5792260deaabc1ce33678351e5