@frog@emersion The wayland-protocols governance model was created in the early days. People wanted lots of features in, we feared that many of them are designed like X11 and violate the Wayland design principles, and so there was more disagreement than agreement on how to design things in order to get the features end users need. We always wanted downstream projects to develop extensions first for themselves, then see if they work for others as well.
@frog@emersion A big problem with Wayland extension is that their stability requirements are greater than those of a library ABI. If a library breaks ABI, one can at least vendor an old copy of the library with an app. That is not possible with Wayland. Protocol fragmentation hurts interoperability, which is why wide agreement on extension is very desirable. Getting wide agreement is also the hard part of design, as everyone knows.
@frog@emersion What are the concerns of easily accepting new extensions into wayland-protocols? Fragmentation, causing interoperability problems between apps and compositors. Some fragmentation is unavoidable, but I think it is still good to at least try to minimize it by looking for wide acceptance. Doing major revisions to extensions is a breaking change too, increasing fragmentation.
@frog@emersion But anyone can just make extensions and ship them outside of wayland-protocols. This was even a goal in the early days when @krh was still developing Wayland. Let downstreams mature extensions, and then let them grow their support organically.
I think that idea still carries, but we need to think how to deal with the fragmentation.
wayland-protocols partly came about from the desire to have "blessed ground" for known-good extensions.
@frog@emersion Some Wayland extensions should get wide agreement, while others are fundamentally enabling something that will never get that wide agreement. A good example are the protocol extensions that make wlroots the modular base for anyone to build a custom environment by choosing and picking helper programs. That design is inherently against the fully integrated product design used by e.g. GNOME. Both have good reasons to exist.
@frog@emersion I think in the past at least some people have seen the acceptance to wayland-protocols as means to force everyone to support the extension. It does not work like that. Some extensions should get wide adoption, others do not need to. That is how the wayland-protocols namespaces wp, xdg, and ext came about. It is possible for an ext extension to become widely supported, too, but there is usually not as wide agreement initially that it would have made it into wp.
@pq@frog@emersion@krh I think you've kind of hit the nail on the head as to why we have a problem now and why frog-protocols now exists.
When I talk to folks who develop compositors, the majority of them don't support this idea that protocols need to be perfect before they land. On the contrary, it seems to be burning people out to try to deal with that expectation. Also, I think that the "principles" had little influence on adoption of Wayland, but rather desperation to replace X11.
@pq@frog@emersion@krh In practice, it does not seem to be as hard as it looks to get wide agreement, it's just much harder to get *universal* agreement. It often seems like the latter is necessary to get anything done, and that's something we need to put more effort into squashing.
There also seems to be a fear of "dead batteries", but I don't think that's something we should be concerning ourselves. Things tend to naturally work themselves out over time anyway.
@pq@frog@emersion@krh Wayland, as used today, is already not functional without things that aren't in wayland-protocols. On the GNOME side, there's both private protocols and a mixture of private and public D-Bus interfaces. On the KDE side, they use private protocols and third-party protocols. Most other Wayland environments follow the KDE approach too. A lot of them are the same third-party protocols. That says to me we're not doing a good job of integrating things that are commonly needed.