[PATCH wayland] client: add wl_proxy_get_version function

[Pekka Paalanen]

On Mon, 06 Oct 2014 11:43:56 +0300
Rémi Denis-Courmont <remi at remlab.net> wrote:

> Le 2014-10-06 11:26, Pekka Paalanen a écrit :
> >> > 4 or higher as a wl_surface version 3? If not, I cannot rely on
> >> > 'wl_proxy_get_version(surface) >= 2'...
> >>
> >> Changing the semantics[5] of wl_surface.damage is a good example 
> >> where
> >> this would fail indeed. If a library only knows up to version 3, but
> >> the app gives it a wl_surface of version 4, the damage coordinates
> >> would be wrong.
> >>
> >> Originally we had the idea, that all version bumps are backwards
> >> compatible. Simply testing for version >= X would always work. The
> >> wl_surface.damage change is not backwards compatible in that sense.
> >>
> >> Looks to me like if we don't fix damage, then this versioning 
> >> problem
> >> would be solvable... :-(
> >
> > Oh I'm being silly, we only need to fix damage in a backward 
> > compatible
> > way: add a new request, don't modify the behaviour of the old one.
> >
> > Keeping backward compatibility wrt. version >= X checks seems like a
> > good idea and should reduce the problem set somewhat.
> 
> You could stick to adding new requests rather than redefine existing 
> ones.
> 
> But what about events. AFAICT, they would still require either:
> - never adding events in new versions,
>   or
>    - adding events that only fire after a new requests was sent,
>     and
>    - never copying the listener structure ever in the client library
>      (to prevent out-of-bounds read).
> 
> Otherwise, it would still fail the code path setting the object 
> listener targets an older interface version than the code path creating 
> the object.

Is there any case where one would copy a listener struct?

Currently we rely on the server knowing the supported interface
version, so that it will never attempt to send an event the client
cannot handle. Therefore using old listener structs that lack entries
should be safe, when the version is negotiated properly.

The remaining problem here is communicating the correct supported
version to the server, isn't it?

Could this be solved (completely?) by saying that libraries that take
existing wl_proxy objects such that they
a) set up listeners, or
b) create new wl_proxies from it and set their listeners;
need to also offer API to tell which versions of the passed in
wl_proxies they support?

We somehow implement the interface version inheritance in
libwayland-client and offer wl_proxy_get_version().

A client library can use wl_proxy_get_version() to check the
effective interface version as necessary, and if it does a) or b), fail
if the effective version is greater than what they support. That
failure would be a bug in the application, because it didn't take
the library's supported version range into account.

Does this make sense?
Would this be a complete solution?
Any other ideas?

As a detail, this should work just fine for EGL which takes existing
wl_surface proxies. EGL does not set up any listeners, and it only
creates wl_callback objects through the passed-in wl_surface proxy,
which cannot cause a version mismatch.

It would be nice to be able to add events to interfaces, and we have
already done that, so forbidding it now is probably too much.

Requiring an event-opt-in request to be sent probably does not solve
anything either. It is quite equivalent to the effective interface
version communicated to the server, and app code can send it anyway
before giving the wl_proxy to a library.


Thanks,
pq