Protocol backwards compatibility requirements?

[Scott Anderson]

On 21/04/20 12:57 pm, Christopher James Halse Rogers wrote:
> On Mon, Apr 20, 2020 at 15:05, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> On Thu, 16 Apr 2020 17:47:56 +1000
>> Christopher James Halse Rogers <chris at cooperteam.net> wrote:
>>
>>>  On Wed, Apr 15, 2020 at 14:27, Simon Ser <contact at emersion.fr> wrote:
>>>  > Hi,
>>>  >
>>>  > On Monday, April 13, 2020 1:59 AM, Peter Hutterer
>>>  > <peter.hutterer at who-t.net> wrote:
>>>  >>  Hi all,
>>>  >>
>>>  >>  This is request for comments on the exact requirements for protocol
>>>  >>  backwards compatibility for clients binding to new versions of an
>>>  >> interface.
>>>  >>  Reason for this are the high-resolution wheel scrolling patches:
>>>  >> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
>>>  >>
>>>  >>  Specifically, the question is: do we **change** protocol 
>>> elements or
>>>  >>  behaviour as the interface versions increase? A few random 
>>> examples:
>>>  >
>>>  > What we can't do is:
>>>  >
>>>  > - Change existing messages' signature
>>>  > - Completely remove a message
>>
>> Indeed.
>>
>>>
>>>  It should be relatively easy to modify wayland-scanner to support both
>>>  of these things, *if* we decide that it's a reasonable thing to do.
>>>  (You'd do something like add support for <request name="foo"
>>>  removed_in="5"/> and the like)
>>
>> How would that work, given the version is negotiated at runtime?
>>
>> The message signature structs are now ABI as well, and we have no room
>> for alternate signatures, do we?
> 
> Sure we do. Internally we can just give them different names, with 
> different contents, and switch based on the version requested at runtime.
> 
>  From the client API side it's more difficult (at least for requests), 
> because we can't remove any symbols - we *can* make it a client error 
> with a good error message, though.
> 
> On the events side it's easier, as we can add a wl_foo_listener_v5 
> struct and wl_foo_add_listener_v5.
> 
> This does add a new sharp edge to the raw wl_proxy_* interface, but 
> client code isn't expected to be using that and this doesn't seem 
> particularly hard for language bindings to adapt to.

There is more than just libwayland and wayland-scanner for C that needs 
to be taken into consideration here. Adding any of these kinds of 
changes requires that _everybody_ updates to handle this, including 
things like the Rust Wayland binding/reimplementation and Qt's own 
Wayland scanner.

I really don't think it's worth the effort.

Scott