[RFC wayland] Track protocol object versions inside wl_proxy.

[Pekka Paalanen]

On Wed, 25 Nov 2015 10:25:42 -0800
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Wed, Nov 25, 2015 at 10:15 AM, Derek Foreman <derekf at osg.samsung.com> wrote:
> > On 13/11/15 12:21 PM, Jason Ekstrand wrote:  
> >> On Fri, Nov 13, 2015 at 3:18 AM, Giulio Camuffo <giuliocamuffo at gmail.com> wrote:  
> >>> So do i understand correctly that if the app creating the
> >>> wl_compositor was built against a libwayland without this patch the
> >>> version returned in mesa by wl_proxy_get_version() for every proxy
> >>> will be always 1?  
> >>
> >> Yes, see also the second e-mail link below.  I proposed to make
> >> wl_display version 0 so that libraries can detect whether the client
> >> was built against old or new libwayland.
> >>
> >> --Jason  
> >
> > But the generated protocol headers won't have wl_surface_get_version()
> > in that case, so build would fail?
> >
> > I'm finally trying to build a client that shows this failure mode, and
> > it's starting to feel quite contrived...  
> 
> The issue that arises is if you have a client built against an old
> version of libwayland that uses a library built against a newer
> version.  Let's make this extremely concrete:
> 
> Suppose that we use this wl_surface_get_version() in mesa's EGL
> implementation to determine whether or not we have a buffer_damage
> request.  We do that, merge it into mesa master, and start shipping it
> in distros.  Then some old client comes along that was built against
> libwayland 1.3.  It can run against libwayland 1.7 just fine because
> everything's backwards compaible.  It can also run against our
> brand-new mesa because the GL and EGL apis are backwards compatible.
> However, whatever wayland objects it passes in to EGL will be created
> using the old api that doesn't have _versioned functions.  The result
> of this is that all objects appear to be version 1 because that's what
> wl_display starts at.
> 
> This is ok for buffer_damage() because that's just adding a request.
> However, if there's something more subtle that happens when an object
> changes version such that treating a version 3 object as a version 1
> object may not always be correct, then we have a problem.  While, in
> general, we should try to avoid these kinds of changes, they can
> happen so we should let the user of wl_proxy_get_version() be able to
> distinguish between version 1 and "I don't know".

Hi,

FYI, I've been thinking about this small detail. Binding an object with
version 3, and then using it like you'd use version 1 object is
something we do all the time everywhere without even realizing. I don't
think we can or should ever break that compatibility - nowdays I think
it is part of the protocol stability promise.

I think this is also part of the reason we started to favour adding a
new request rather than making the semantics of an existing one
version-dependent.

This is not a comment against the "unversioned version" concept at all,
it is a rule I believe we should follow in protocol design. However, I
bet someone eventually manages to create a mess where changing
behaviour by version becomes the only solution, so "unversioned
version" will probably become useful. But it should be a last resort.

Re: versioning wl_display itself, I agree with Jason that it doesn't
matter: wl_display cannot really be extended anyway. We have no way to
negotiate a new version for it - libwayland-client would need to
internally create a wl_registry, fish out a new wl_display global, bind
it with a new version, and then replace the old object with it somehow.
I shudder to think of a situation where this would be necessary...


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151207/94831ddd/attachment-0001.sig>