State of Wayland protocol development

Fri Sep 25 10:02:00 PDT 2015

On 20/09/15 10:49 PM, Jonas Ådahl wrote:
> On Sun, Sep 20, 2015 at 08:28:08PM -0700, Jasper St. Pierre wrote:
>> We can pick any number of strategies to deal with unstable protocols.
>> We can give it a special name, we can say that any version < 1000 is
>> considered unstable, we can use a special request. That's not too
>> important -- we're all aware of how to implement that.
>>
>> The more important issue, for me, at least, is how to deal with the
>> gatekeeper-ness of Wayland and resulting slow development.
> 
> Indeed. The point of this thread is to come up with a way to deal with
> this more efficiently.
> 
>>
>> I do think
>> it would be nice to have a place for protocols to flounder on their
>> own that isn't Weston, and isn't GNOME/KDE/EFL. I also think it should
>> be possible to install these by default, but put them in an unstable/
>> directory, so that users who want to play around with a protocol can
>> do that.
> 
> I think it would make sense to have such a repository if we decide that
> an unstable protocol we agree on should be part of the stable set of
> official extensions does NOT need a weston implementation to get that
> status, it'd make sense to have a wayland-protocol repository for this.

We've already decided that weston isn't a "desktop environment", so it
seems like a next logical step is concluding that there will be protocol
intended to be shared amongst desktop environments that weston is not
going to implement?

>>
>> I would be fine with checking these protocols into the wayland repo,
>> or having a separate repo for them, but I do think they need a home,
>> where a lot of people can hack on experimental stuff without having to
>> go through a mailing list.
> 
> I don't think people should be able to hack and make arbitrary changes
> to protocols that should be considered a common ground without having to
> got through public review. The point of going through a central point is
> to have it peer reviewed and stamped "good enough" for an in-progress
> protocol that is deemed to, some time in the future, be declared a stable
> official protocol extension. I'm not objecting to the current ways of
> having requirements on things like we have, just that we need to adjust
> our requirements so that we can lower the barrier some, not completely.

While keeping the peer review requirement, moving some protocol out of
weston removes the need to get a weston implementation peer reviewed at
the same time as the protocol changes...  (I'm not 100% sure that's a
good thing, though.  Certainly EFL has used weston's impementations as
reference for a few bits of protocol.)

> For faster iteration protocol development without any need for peer
> review and discussion could IMO just live in topic branches, and when
> there is something that seems like a thing that can be implemented in
> more than one place, it could go through our public peer review process
> and later be released as part of a wayland-protocol or weston release.

I worry about multiple branches making it hard to use multiple "bleeding
edge" protocol specs at the same time - though I have no better ideas.

> Also, for making unstable protocol installable, we'd have to make them
> installed on a per release directory, and a user of these have to have
> non-trivial version tracking in order to get the correct XML from the
> correct release

This would be a nice problem to solve, though. :/

Right now I think we're all just copying xml files from weston into
other repositories, which is far from ideal.

> 
> 
> Jonas
> 
>>
>> Additionally, I think we should start building tools and
>> infrastructure so that people can use distributed protocol files --
>> putting everything in wayland.xml and turning it into C ABI isn't
>> particularly appealing to me.
>>
>> On Sun, Sep 20, 2015 at 8:04 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
>>> On Sat, Sep 19, 2015 at 10:35:19AM +0300, Giulio Camuffo wrote:
>>>> 2015-09-19 4:24 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
>>>>> On Fri, Sep 18, 2015 at 07:12:10PM +0300, Giulio Camuffo wrote:
>>>>>> 2015-09-18 17:44 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
>>>>>>> On Fri, Sep 18, 2015 at 04:35:52PM +0300, Pekka Paalanen wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>>>
>>>>>>>> What do you do when you do a backward-incompatible change to a protocol?
>>>>>>>>
>>>>>>>> - Rename the globals or the protocol file? This would make people think
>>>>>>>>   twice about the change as it would incur lots of churn in the code.
>>>>>>>>   The churn shouldn't be a problem for review, since we wouldn't review
>>>>>>>>   experimental implementations carefully. But it's still churn.
>>>>>>>
>>>>>>> The way I've done it and also the way we did with pointer gestures is to
>>>>>>> prefix all of the interfaces with an underscore, with a note in the
>>>>>>> global interface's description describing the limitations and lack of
>>>>>>> backward compatibility as well as future intentions. See here[0] for
>>>>>>> exact wording.
>>>>>>>
>>>>>>> A protocol bump can be backward compatible "by accident" and it'd be up
>>>>>>> to the protocol designer to decide whether she/he wants to state any
>>>>>>> compatibility, but the main idea is that a client should only bind the
>>>>>>> exact same version it implements, and a server should terminate a client
>>>>>>> that tries to bind an incompatible version.
>>>>>>
>>>>>> We could also add a "_N" suffix to the interface name, where N would
>>>>>> be the version number. This way a client can easily check the version
>>>>>> of the interface implemented and only bind the global name with the
>>>>>> right version, and at the same time it allows to do backward
>>>>>> compatible changes to the interface by increasing the normal interface
>>>>>> version.
>>>>>> Moreover, if a compositor feels like it, it can implement many
>>>>>> different incompatible versions of the interface at the same time.
>>>>>> When stable, the _N suffix would be removed.
>>>>>
>>>>> The version number would already be easily checkable as it is part of
>>>>> the advertisement. What it would stop, however, is the possibility to have
>>>>> backward compatible revisions of an experimental protocol since every
>>>>> revision would change the interface name. So I don't think "_N" suffix is
>>>>> desirable, since I think its more important to support potential
>>>>> backward compatibility of experimental interfaces than multiple
>>>>> implemented incompatible versions.
>>>>
>>>> A suffix would also allow compatible changes, you just need to not
>>>> bump the suffix unless the change you're doing is backward
>>>> incompatible. The _N suffix would be the major version number, the
>>>> normal interface version would be the minor number. You bump the major
>>>> if you're breaking compatibility, otherwise you bump the minor.
>>>> My understanding of your proposal was that apps would need to bind the
>>>> global only if the version is exactly the same as the one it
>>>> implements, so that instead would not allow backward compatible
>>>> changes. Did i misunderstand?
>>>
>>> Ah, so you meant to add major/minor versioning. I guess that could work,
>>> but I wonder if its worth the effort. I think one generally should
>>> consider an experimental protocol to be still experimental and not
>>> something one can rely on, and I'm not sure I'd want to support multiple
>>> versions of an experimental protocol implementations anyway; but sure, it
>>> would work just fine. In the end I think whoever designs a protocol can
>>> make the call whether it is worth the effort of having major/minor version
>>> seperation, and doesn't even need to decide it up front, as the a client
>>> probably wouldn't even parse the suffix; as long as the names are
>>> different it doesn't matter much what the difference is.
>>>
>>>
>>> Jonas
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>>
>> -- 
>>   Jasper
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 