State of Wayland protocol development

[Pekka Paalanen]

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?

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.

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151012/b7bc8691/attachment.sig>