From kde-release-team Sat Apr 04 14:20:21 2020 From: Kevin Ottens Date: Sat, 04 Apr 2020 14:20:21 +0000 To: kde-release-team Subject: Re: New Framework Review: KDAV Message-Id: <2711594.bh9x1ujFaH () wintermute> X-MARC-Message: https://marc.info/?l=kde-release-team&m=158601004832648 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2580658.5ouunz3rvE" --nextPart2580658.5ouunz3rvE Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > during Akademy there was a request to promote KDAV from KDE PIM to > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > would be classified as a functional tier 3 framework. > > So far we have fixed a number of obvious ABI-compatibility issues, removed > QtXml[Patterns] usage from the public interface and relicensed GPL parts > (apart from a bit of test code) to LGPL. The next step would be a more > thorough review to identify changes necessary before becoming a Framework. > > To avoid the last minute invasive changes we ended up doing for > KCalendarCore, I'd propose the following timeline: > > - identify and implement all necessary changes to the API and ABI until the > 20.04 Application release (that includes the still necessary move to the KF5 > library namespace). I'm likely late to the party, but here is what I found by looking at KDAV master today (first day of the KDE PIM sprint): * There's a few private methods or Q_SLOTS that I'd hide completely by moving them to the d-pointer, for the slots we're using type safe connects so they don't even need to be marked as slots at all; * Is it worth making DavCollection moveable? It's only copyable right now; * We might want to do something about "ctag" in DavCollection it's a bit obscure as a name (and the API doc doesn't help), also it seems to not be an official standard (while being widely supported) and there's the sync-token mechanism which has a RFC (RFC6578); * Why isn't DavCollectionModifyJob using DavCollection somehow? (might just be my ignorance but I find it surprising that it is solely based on a property mechanism); * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on its collectionDiscovered signal, is it really necessary? if it has to stay, shouldn't be at least documented? or at least a safer type than int? * DavCollectionsMultiFetchJob is inconsistent as it's not using Q_DECLARE_PRIVATE; * KDAV::Error would benefit from more apidox; * Is it worth making DavItem moveable? It's only copyable right now; * Same comment about etag for DavItem than the ctag one for DavCollection * I'd be tempted to move all the protected methods of DavJobBase on its d- pointer, the job subclasses would have access to them anyway, it'd make sense to put them protected in the header only if we expect subclasses outside of the lib (and I doubt this is actually supported); * It needs to decide between Qt smart pointers or STL ones I think, found a bit of both so far (I'd lean toward STL ones but maybe that's just me); * Make DavUrl moveable? * EtagCache probably shouldn't have anything protected, also, why is it a QObject at all? * Are we sure we want to return a QLatin1String in ProtocolInfo? this strike me as an odd choice. Overall apidox would likely need a big pass of cleanups as well. I think that's it from me. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en --nextPart2580658.5ouunz3rvE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQXFmpSdcX6bxpI/XgHS7vLjezJ4gUCXoiXpQAKCRAHS7vLjezJ 4vgaAJ4jpleQxSAU+0lhJKPRcxFNSyn28wCgho/79itgLQZCz7+21fo8GYegsYk= =7NU+ -----END PGP SIGNATURE----- --nextPart2580658.5ouunz3rvE--