State of Wayland protocol development

[Pekka Paalanen]

On Mon, 12 Oct 2015 15:18:47 +0800
Jonas Ådahl <jadahl at gmail.com> wrote:

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

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

I agree having it on the name. I would not like repurposing the
interface version in any case.


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

Compositors I don't know, but I'm pretty sure there is GStreamer code
somewhere using it. So, I'd rather rename, just in case. (Renaming
isn't the blocker, my priority queue of tasks is. :-)

Besides, Weston already implements it, so it's nice to not crash a gst
app if they happen to disagree, even if the app was just a demo.

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

Yup, I understood so already.


> > 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/748c493b/attachment.sig>