KDav without KIO

[Christian Mollekopf]

On Mon, Jun 26, 2017, at 11:45 AM, laurent Montel wrote:
> Le lundi 26 juin 2017, 11:08:1 CSTLuca Beltrame a écrit :
> > Il giorno Mon, 26 Jun 2017 10:45:26 +0200
> > 
> >Christian Mollekopf <chrigi_1 at fastmail.fm> ha scritto:
> > > I'm not even building kdepim, so I can't offer that, sorry. Perhaps
> > > Sandro can given he's the one that ported the resource to kdav.
> > 
> > As a downstream packager, I'd give a -1 to merging this (FWIW) unless
> > it has been at least superficially tested with the current PIM (not that
> > *you* have to do so, but as long as *someone* does that).
> > 
> > The DAV resource is exceptionally quirky by itself (according to my
> > unspecific experience in the KDE Community Forums), so better to not add
> > additional (potential) regressions.
> 
> Indeed we need be sure that there is not regressions.

I agree with you and Luca, if you want to use this in kdepim, then
somebody will have to test it and fix problems if there are any.
I'm happy to work on specific defects in the kdav code, but I'm not
going to make sure the dav resource has no regressions.

> But as I read your previous email you don't build kdepim, so how you can
> be sure that there is not regression  ?

I'm not sure and I don't think it's my responsibility either.
I don't expect any regressions, I think the library is still
functionally the same (apart from the issues pointed out by Daniel), but
I have no way of knowing.

> What is you test plan against kdepim  ?

There is no plan. I'm only testing what I need in Sink and I made sure
the existing tests pass,
and that's all I plan to do in that regard.

> Do you implement new autotests  ?

I might in the future, I did not implement any additional tests so far.

> Do you compare with current code  ?

The API is still the same, it seems functionally the same so far, except
for KIO magic as Daniel pointed out.

> Etc.
> 
> We don't want a code which work for kolabsys and totally broken in
> kdepim.
> 

Understandable.

> As I know that you don't read bugs.kde.org :) so for sure all regression
> will not be fix :)

That is correct, I'm not maintaining the DAV resource and will not look
into any DAV resource problems.

Just to give you my perspective; I understand why my stance may be
problematic for you, after all you want to keep kdepim in good shape, so
these are perhaps all necessary steps to take.
But there is a reason why I've started Kube and stopped working on
Kontact and I can absolutely not afford to maintain Kontact
while building Kube, nor do I have any interest in doing so.
We required a solution for DAV protocols for Kube/Sink and I've asked
Sandro to create a library for that (given that I couldn't find anything
suitable that already exists), and pointed him to the DAV resource which
seemed to have a fairly complete implementation of what we require.
While it was clear from the beginning that KIO will have to go (it's
just the wrong technology for our usecase IMO), we didn't get to that
until now but instead have the DAV resource ported to KDav already
(which I suppose makes sense to the end of untangling the Akonadi bits
that used to be in there).
Now I think it's great if can share the DAV implementation between Kube
and kdepim, but all that I ever wanted out of this exercise is a
functional, reasonably stable DAV implementation that is fairly
self-contained and portable, and doesn't have all sorts of dependencies.

I think there are a few ways forward:
* Somebody steps up and does the necessary DAV Resource work so we can
move forward.
* You agree that this is generally the right direction and overall a
better solution (I know I do), but you can't do the work right now.
Given this is an intrusive change (although currently without API
changes), we could argue we just bump to KDav2 (notwithstanding that we
have a completely different version number in the CMakeFile...), so you
can stick to what you use now and move at your own pace. This would be
pretty much the same as KIMAP2.
* You disagree with the direction and I'll have to figure out a sensible
name for my new library.

I hope we can do either solution 1 or 2, because those seem the most
sensible to me.
Anyways, I hope this perhaps explains my situation better =)

Cheers,
Christian