On 21/04/20 12:57 pm, Christopher James Halse Rogers wrote:
On Mon, Apr 20, 2020 at 15:05, Pekka Paalanen <ppaala...@gmail.com> wrote:
On Thu, 16 Apr 2020 17:47:56 +1000
Christopher James Halse Rogers <ch...@cooperteam.net> wrote:
On Wed, Apr 15, 2020 at 14:27, Simon Ser <cont...@emersion.fr> wrote:
> Hi,
>
> On Monday, April 13, 2020 1:59 AM, Peter Hutterer
> <peter.hutte...@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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
