Problems in KWayland causes by API and ABI compatibility promises

[Vlad Zahorodnii]

Hi,

On 3/24/20 4:35 PM, Aleix Pol wrote:
> We can decide what we want for KF6 and act accordingly. If for
> example, we were to split kwayland into kwaylandclient and
> kwaylandserver and the latter be in plasma, we could consider putting
> new code in KWin or a shared repository.

I was also thinking about splitting KWayland into KWaylandClient and 
KWaylandServer. However, later on, I realized that this is a bad idea 
because it'll make implementing new protocols more difficult and testing
wrappers will become more difficult. In fact, I don't think that we'll 
be able to keep existing tests in the kwayland repo; we will probably 
have to drop them.

> In fact, if we ever want to have such a kwayland server and are
> serious about it, we'll want to be mindful about what we put there.
> Much like any other framework, we only put things on the framework
> when it's going to be shared rather than putting some parts of the
> code somewhere by policy like we've been doing here.

The problem is that we can't keep KWayland stable; at least, right now. 
There are still things in the wild that need a protocol or something and 
as we implement those protocols, we might need some of existing wrappers 
to adapt to the new changes or rework them completely. One such example 
that comes to my mind is the explicit synchronization protocol.

I think it's a good thing to have helper classes for Wayland protocols 
that you could plug in and get a running compositor, this is a great 
idea, but I think it's way too early to promise API and ABI guarantees.

Cheers,
Vlad