[RFC wayland] Track protocol object versions inside wl_proxy.

[Derek Foreman]

Just a quick ping on this because conversation has died down and nobody
actually gave a RB or any suggestions for change.

Someone flagged the patch as RFC in patchwork so it disappeared and I'm
wondering if people may have thought it landed...

Where are we at with this?

I got Jason's RB on my trivial follow up that makes display's version 0.

Should I squash that patch into this one and repost?  (That way we won't
have a commit with potentially weird behaviour...)

On 07/12/15 09:20 AM, Pekka Paalanen wrote:
> 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
> 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>