State of Wayland protocol development

[Jasper St. Pierre]

We can pick any number of strategies to deal with unstable protocols.
We can give it a special name, we can say that any version < 1000 is
considered unstable, we can use a special request. That's not too
important -- we're all aware of how to implement that.

The more important issue, for me, at least, is how to deal with the
gatekeeper-ness of Wayland and resulting slow development. I do think
it would be nice to have a place for protocols to flounder on their
own that isn't Weston, and isn't GNOME/KDE/EFL. I also think it should
be possible to install these by default, but put them in an unstable/
directory, so that users who want to play around with a protocol can
do that.

I would be fine with checking these protocols into the wayland repo,
or having a separate repo for them, but I do think they need a home,
where a lot of people can hack on experimental stuff without having to
go through a mailing list.

Additionally, I think we should start building tools and
infrastructure so that people can use distributed protocol files --
putting everything in wayland.xml and turning it into C ABI isn't
particularly appealing to me.

On Sun, Sep 20, 2015 at 8:04 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Sat, Sep 19, 2015 at 10:35:19AM +0300, Giulio Camuffo wrote:
>> 2015-09-19 4:24 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
>> > On Fri, Sep 18, 2015 at 07:12:10PM +0300, Giulio Camuffo wrote:
>> >> 2015-09-18 17:44 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
>> >> > On Fri, Sep 18, 2015 at 04:35:52PM +0300, Pekka Paalanen wrote:
>> >
>> > <snip>
>> >
>> >> >>
>> >> >> What do you do when you do a backward-incompatible change to a protocol?
>> >> >>
>> >> >> - Rename the globals or the protocol file? This would make people think
>> >> >>   twice about the change as it would incur lots of churn in the code.
>> >> >>   The churn shouldn't be a problem for review, since we wouldn't review
>> >> >>   experimental implementations carefully. But it's still churn.
>> >> >
>> >> > The way I've done it and also the way we did with pointer gestures is to
>> >> > prefix all of the interfaces with an underscore, with a note in the
>> >> > global interface's description describing the limitations and lack of
>> >> > backward compatibility as well as future intentions. See here[0] for
>> >> > exact wording.
>> >> >
>> >> > A protocol bump can be backward compatible "by accident" and it'd be up
>> >> > to the protocol designer to decide whether she/he wants to state any
>> >> > compatibility, but the main idea is that a client should only bind the
>> >> > exact same version it implements, and a server should terminate a client
>> >> > that tries to bind an incompatible version.
>> >>
>> >> We could also add a "_N" suffix to the interface name, where N would
>> >> be the version number. This way a client can easily check the version
>> >> of the interface implemented and only bind the global name with the
>> >> right version, and at the same time it allows to do backward
>> >> compatible changes to the interface by increasing the normal interface
>> >> version.
>> >> Moreover, if a compositor feels like it, it can implement many
>> >> different incompatible versions of the interface at the same time.
>> >> When stable, the _N suffix would be removed.
>> >
>> > The version number would already be easily checkable as it is part of
>> > the advertisement. What it would stop, however, is the possibility to have
>> > backward compatible revisions of an experimental protocol since every
>> > revision would change the interface name. So I don't think "_N" suffix is
>> > desirable, since I think its more important to support potential
>> > backward compatibility of experimental interfaces than multiple
>> > implemented incompatible versions.
>>
>> A suffix would also allow compatible changes, you just need to not
>> bump the suffix unless the change you're doing is backward
>> incompatible. The _N suffix would be the major version number, the
>> normal interface version would be the minor number. You bump the major
>> if you're breaking compatibility, otherwise you bump the minor.
>> My understanding of your proposal was that apps would need to bind the
>> global only if the version is exactly the same as the one it
>> implements, so that instead would not allow backward compatible
>> changes. Did i misunderstand?
>
> Ah, so you meant to add major/minor versioning. I guess that could work,
> but I wonder if its worth the effort. I think one generally should
> consider an experimental protocol to be still experimental and not
> something one can rely on, and I'm not sure I'd want to support multiple
> versions of an experimental protocol implementations anyway; but sure, it
> would work just fine. In the end I think whoever designs a protocol can
> make the call whether it is worth the effort of having major/minor version
> seperation, and doesn't even need to decide it up front, as the a client
> probably wouldn't even parse the suffix; as long as the names are
> different it doesn't matter much what the difference is.
>
>
> Jonas
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper