State of Wayland protocol development

[Jonas Ådahl]

On Mon, Oct 12, 2015 at 10:07:19AM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2015 15:24:04 +0100
> Daniel Stone <daniel at fooishbar.org> wrote:
> 
> > On 9 October 2015 at 14:36, Jonas Ådahl <jadahl at gmail.com> wrote:
> > > On Fri, Oct 09, 2015 at 02:11:28PM +0100, Daniel Stone wrote:
> 
> > >> >> > 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.
> > >>
> > >> Unfortunately it does, and I think it makes newer g++ in particular
> > >> quite unhappy. dmabuf is currently using 'z' as an experimental
> > >> prefix, which seems reasonable enough - but again that falls into the
> > >> stable-naming problem. If zlinux_dmabuf v7 is the blessed stable
> > >> version, then it means clients written to zlinux_dmabuf v7 have to
> > >> completely unnecessarily port everything to being linux_dmabuf v1. I'd
> > >> be much more in favour of keeping a single stable name throughout its
> > >> development.
> > >
> > > My idea of this is that, an experimental/unstable protocol is just that.
> > > When declared stable, it's more or lesst the final break. If you want to
> > > have linux_dmabuf with no special unstable naming during all of its
> > > development stages, then that means you start being stable at version 1,
> > > with the difference that it may be incomplete. The point of unstable
> > > protocols is that changes may break the protocol, and to make tha
> > > possible, we need to do a rename when declaring it stable. It's the pain
> > > that comes with being an early adopter, while still enabling the
> > > possibility to actually fix the protocol during its early stages instead
> > > of duct tape it.
> > >
> > > If you see some way to avoid renaming then please explain, because its
> > > not clear to me how (across multiple projects and code bases) it'd work.
> > 
> > Oh, sure. I was just hoping to avoid, if possible, the following kind
> > of situation:
> >   - zlinux_dmabuf v4 (or whatever) gets widely deployed in GStreamer,
> > Weston and Mutter
> >   - everyone agrees it's perfect and that exact protocol becomes linux_dmabuf v1
> >   - everyone now needs to either support both, or break backwards compatibility
> > 
> > For similar reasons, everyone doing voice calls ended up implementing
> > the org.freedesktop.Telepathy.CallDRAFT interface.
> > 
> > But I get that our protocol versioning should really be additive -
> > i.e. no rewriting of existing requests - so that's fair enough I
> > guess.
> 
> Renaming the XML file is a sure way to indicate at build time which
> incompatible version is required.
> 
> We will also need renaming all the related globals, so that a client
> compiled with one incompatible version will not try to bind the
> interface of a server compiled with a different incompatible version.
> 
> This is more graceful than what we tried with xdg-shell's do-or-die
> experimental versioning which was basically non-detectable at runtime.
> 
> If we really need to do incompatible changes, then I do not see a way
> to avoid the renames.
> 
> The open question here that I see is that should we expect a final
> break at stabilization time to move on to a "proper" name, or end up
> using zlinux_dmabuf_v4 for the stable iteration rather than
> linux_dmabuf, for instance.
> 
> On one hand, using linux_dmabuf_v4_create_params() looks a little odd
> to me, OTOH having to fix everything at stabilization time is slightly
> annoying too.
> 
> We should favour non-breaking changes, sure, but sometimes it's better
> to clean things up.
> 
> Should we encode experimental version in the global interface name or
> not?

Either we encode the version in the name together with a prefix, or we
only have a prefix and redefine the meaning of the interface version.
I'm fine with having it in the name, allowing compatible changes during
the unstable phase.

> 
> If we do, we might be inclined to do an "unneeded" rename when we
> decide the interface is stable. If we do not, we might end up with the
> problem that wl_scaler has right now: I would like to clean up the
> interface, but the change will be incompatible, so I have to come up
> with a new name. Coming up with good names is one of the hardest things
> in programming, IMO.

I wonder, has anyone else implemented it? Maybe you can get away with a
not renaming it before its too late.

> 
> Are we all ok with the final break caused by the rename, even if there
> were no incompatible changes?

I'm in favor of a final rename of the global, the protocol name and the
XML file name when declaring stable.


Jonas

> 
> I think we should expect to have incompatible changes during protocol
> development, and not having any would be the exception, so I am fine
> with the final mandatory rename.
> 
> 
> Thanks,
> pq