Protocol backwards compatibility requirements?

[Peter Hutterer]

On Tue, Apr 21, 2020 at 11:50:27AM +0300, Pekka Paalanen wrote:
[...]
> > > If you're asking if the implementation for version < N could be
> > > deleted or avoided, then I'd say no. Definitely no for desktop
> > > compositors, probably no for anything else public.  
> > 
> > The sub-interfaces are inseparable from the seats, that's set in stone. The
> > question here is less about mixing versions within the seat but more
> > about skipping versions without harm. Let's say wl_pointer version 9
> > introduces wl_pointer.pressure, something independent of anything else
> > else in the wl_pointer interface. Qt (iirc) never implemented axis_discrete
> > handling but it let's say it wants support for pressure.
> > 
> > Guaranteed backwards compatibility means Qt can bump to version 9, implement
> > noop functions for axis_source and axis_discrete and done. 
> > 
> > Allowing events to change between versions means that Qt now also needs to
> > update its handling of whatever changed between those versions, e.g.
> > wl_pointer.axis. A direct jump past versions you don't care about isn't
> > possible.
> 
> I would say that the direct jump past versions is never possible. Like
> you said, Qt still needs to implement the noop functions. If it
> doesn't, it will crash when those events get sent. The fact that making
> those new functions noop is ok is just a detail, an accident of design.
> Qt must come with a valid implementation - what a valid and workable
> implementation is, is just a detail.
> 
> > Also, having written the patches to change wl_pointer.axis_discrete to a 120
> > base value there's another issue: no auto-generated FOO_SINCE_VERSION
> > because this doesn't show up in the protocol itself. So this really flies
> > under the radar and you just have to know about it by reading the
> > documentation.
> 
> Was that one of the breaking changes already done in the past?

so, checking the two examples Simon mentioned:
- wl_data_offer.accept: semantics changed from "yes, I can receive this
  type" to "I have received and processed this type and I'm done now".
- xdg_output.description: event was only sent once, changed to sent multiple
  times. Notable: xdg_output is still officially unstable anyway.

So a change in message semantics and how often a message can be received but
not in the actual data delivered. Not directly comparable to a potential
change in the value ranges of an event.
 
> Sounds to me like it's just one more reason to not change existing
> message semantics, and add new messages instead.
> 
> Maybe one possibility with e.g. wl_pointer, if you actually want to
> shed the old cruft, is to create interface wl_pointer2 and add
> get_pointer2 request to wl_seat. We will never be able to get rid of
> the original wl_pointer interface or its implementations, but at least
> it would be clearly separate.

Good point, but I don't think it's worth it. For something that's moving
more frequently this may help, but I don't anticipate a lot of wl_pointer
changes. So this would require double the boilerplate everywhere whith very
little benefit.

Cheers,
   Peter