State of Wayland protocol development

[Daniel Stone]

Hi,

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:
>> Excellent. One really important thing I think to have would be some
>> documentation around the protocol: what are the known open issues /
>> missing pieces / pitfalls? What is the rough plan going forward - is
>> it expected to be marked stable imminently, or expected to be
>> rewritten? We should really make this a hard requirement, rather than
>> having to search through the list every time to remember the most
>> recent discussion on it.
>
> I wonder if this could be done via directory structure. Something like:
>
> stable/ - .. well, stable
> unstable/ - in-progress, future goal is being declared stable
> deprecated/ - deprecated for some other reason, at some point removed
>
> With each protocol having a README with some kind of plan / status and
> a list of maintainers.

Ack.

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

>>   - if none, I can create the repository then, with the usual Wayland ACL
>>   - patch Weston master to include protocols as a submodule
>>   - patch Weston to move its development protocols (xdg-shell,
>> linux-dmabuf, presentation_timing, scaler) to protocols
>>   - go ahead and commit the protocols you and Carlos have been working
>> on (gestures, pointer-lock/rel-pointer, new DnD)
>>   - document all of the above
>
> Sounds like a plan to me, except the DND changes poke at wayland.xml and
> moving wayland.xml into wayland-protocols/ is not something I've thought
> very much about. Should we?

Not really, because libwayland-client also contains all the protocol
implementations for wayland.xml, so I'd be pretty nervous about moving
those out externally.

Cheers,
Daniel