Protocol backwards compatibility requirements?

[Adam Jackson]

On Mon, 2020-04-20 at 15:05 +0300, Pekka Paalanen 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?
> 
> > >   
> > > >  - event wl_foo.bar introduced in version N sends a wl_fixed in
> > > >    surface coordinates. version N+1 changes this to a normalized
> > > >    [-10000, +10000] range.  
> > > 
> > > Argument types can't be changed. This would be a breaking change for 
> > > the
> > > generated code, we can't do that.  
> > 
> > But this isn't changing the argument type; it's changing the 
> > interpretation of the argument.
> > In both cases the type is wl_fixed; in the first you interpret this 
> > wl_fixed as being in surface coordinates, in the second you interpret 
> > it differently.
> > 
> > This doesn't require any changes to code generation; I don't think this 
> > is (in principle) any more disruptive than changing “wl_foo.baz is 
> > sent exactly once” to “wl_foo.baz is sent zero or more times”, 
> > which you're happy with.
> 
> Something we rarely consider is if you pass Wayland protocol objects
> into a library without negotiating the object version with the library
> first. For example, we pass wl_surface into the EGL Wayland wrapper
> library. If wl_surface would get a version bump breaking backwards
> compatibility, meaning that version N+1 changes something that existed
> in version N, the library handling only version N would fall apart.
> 
> I sincerely hope this is the only case of a library taking a ready-made
> Wayland object in. Getting the version negotiation right needs
> inconvenient additions to the library API that I don't think many would
> bother or even realize it's needed.
> 
> You can query the version of a wl_proxy, sure, but that does not help
> you if it returns a number larger than what your code knows about.
> 
> Btw. this is also a problem in the opposite direction. Let's say you
> use a toolkit and the toolkit allows you access to the Wayland protocol
> objects. Then the toolkit gains support for new interface versions and
> uses them, but your app code is not updated. If the protocol change is
> backwards incompatible, your app code may break even if only behaviour
> changes and not signatures.

Yeah, pretty sure we hit this more than once with XI2. X11 has this
property too, the client is not monolithic and different parts of it
expect different protocol versions and want their own interaction with
the protocol stream. If that includes event delivery you suddenly need
to be very careful that the app doesn't deselect the events you need...

I believe some protocols address this by putting a "channel"
abstraction just beneath the client: one socket connection, N channels,
each channel has its own ID space, you can share resources among
compatible channels but it's an explicit import operation. In X11 terms
you could have the GL driver select for the Present / MIT-SHM
completion event in its own channel without stomping on the client's
main loop state.

Of course, for things like XI2, if you have two channels demanding
different visible behaviour, you're still up a creek. But you would at
least have the possibility that the client could get it right.

- ajax