Problems in KWayland causes by API and ABI compatibility promises

[Kevin Ottens]

Hello,

First, a big fat disclaimer: I'm by no mean expert in what's going on the 
Wayland side, so take what I'll be writing here with truck loads of salt.

I'm jumping in mainly because it looks like you guys are in pain and I'm 
trying to lend a hand to find a way forward. It's obviously written from the 
"dealing with API overtime" point of view which includes horrible trade offs 
we get to make from time to time in KF. ;-)

On Wednesday, 25 March 2020 12:16:58 CET Vlad Zahorodnii wrote:
> 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.

To be honest from the other emails I've seen in this thread I think Aleix is 
very much onto something. To me most of the pain points mentioned early in the 
thread are related to the library trying to do way too much (David's questions 
are illuminating in that regard as well).

That's why trying to reduce the API surface and to focus the library as much 
as possible would be a good thing. Since kwaylandserver seems to be really 
only useful for kwin... no need to keep it in frameworks.

> 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.

Sure, we're in a dire position so no solution will be easy. I understand the 
pain point will be the tests for kwaylandclient but maybe the situation is not 
that bad there.

My gut feeling is that the current tests are done by testing kwayland against 
itself. So it's likely easy to miss issues with those tests. Couldn't a 
compositor stub be written just for the needs of kwaylandclient and run the 
tests against it? If you go low level enough you might even be able to test 
more error cases than before. It's an opportunity right there.

The above raises a question of the amount of effort needed for such a stub 
(IOW, "how much API coverage should it provide?"). This is an obvious concern, 
and once again: the API surface matters.

Is it me or even in kwaylandclient most of it is unused or not very much used? 
>From what was mentioned in this thread it looks like the users are not that 
numerous and that they each only use a couple of types or methods in there. 
Exception to this would likely only be kwin own unit tests.

If I'm correct then next to moving kwaylandserver out, what about also moving 
everything of kwaylandclient which used only in kwin unit tests? Then that's 
less code to maintain and in turn that puts less pressure on the compositor 
stub used in the tests.

> > 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.

Not saying it would be full proof but if the API shrinks as much as I'd expect 
it'd be easier to keep it stable.

> 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.

That said: I think for now it has to stay an idea, we can't have that in KF 
API not for the years to come.

So... what's the course of action I have in mind really? I mentioned dropping 
stuff and we all know we can't really drop anything yet. Here are the steps I 
propose:
 1) identify the few percents of the kwaylandclient API being used outside of 
kwin unit tests (might make sense to distinguish plasma-framework from other 
consumers BTW, we might apply different strategies for this one in case of 
roadblocks, not getting into this yet);
 2) mark all of the kwaylandclient unused API as deprecated and freeze it;
 3) write a compositor stub needed to exercise the non-deprecated API of 
kwaylandclient;
 4) port the kwaylandclient tests to the compositor stub, dropping the tests 
about deprecated API;
 5) take all of kwaylandserver + kwaylandclient and copy it to kwin (likely 
with a rename to avoid symbol clashes);
 6) mark all of kwaylandserver API deprecated and freeze it;
 7) when KF6 gets branched drop all the deprecated APIs.

Again, I'm no Wayland expert so I might be missing some things. In any case: 
yes, this is quite some work and might incur some pain and trade-offs... it's 
unfortunately a price to pay to get out of what seems like a difficult 
situation which will lead to increasing pains over time.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200327/b1e0be11/attachment.sig>