State of Wayland protocol development

Sun Sep 20 20:49:58 PDT 2015

On Sun, Sep 20, 2015 at 08:28:08PM -0700, Jasper St. Pierre wrote:
> 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.

Indeed. The point of this thread is to come up with a way to deal with
this more efficiently.

>
> 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 think it would make sense to have such a repository if we decide that
an unstable protocol we agree on should be part of the stable set of
official extensions does NOT need a weston implementation to get that
status, it'd make sense to have a wayland-protocol repository for this.

> 
> 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.

I don't think people should be able to hack and make arbitrary changes
to protocols that should be considered a common ground without having to
got through public review. The point of going through a central point is
to have it peer reviewed and stamped "good enough" for an in-progress
protocol that is deemed to, some time in the future, be declared a stable
official protocol extension. I'm not objecting to the current ways of
having requirements on things like we have, just that we need to adjust
our requirements so that we can lower the barrier some, not completely.

For faster iteration protocol development without any need for peer
review and discussion could IMO just live in topic branches, and when
there is something that seems like a thing that can be implemented in
more than one place, it could go through our public peer review process
and later be released as part of a wayland-protocol or weston release.

Also, for making unstable protocol installable, we'd have to make them
installed on a per release directory, and a user of these have to have
non-trivial version tracking in order to get the correct XML from the
correct release

Jonas

> 
> 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