KDav without KIO

[Christian Mollekopf]

On Mon, Jun 26, 2017, at 09:45 PM, laurent Montel wrote:
> Le lundi 26 juin 2017, 12:25:14 CEST Christian Mollekopf a écrit :
> > 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.
> 
> As you can see it's a problem as we are not a big team, and main dev of
> dav 
> resource is not active.
> 
> > 
> 
> > 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 =)
> 
> I understand your situation, but if we look at kdepim perspective your
> patch 
> will be not an improvement, you just remove kio support, without adding
> more 
> autotests or make sure that dav resources still work without regressions.
> 
> Actually we have a resource which works, we don't have a maintainer, so
> if we accept your patch without warranty that there is not regressions it will
> be a  big problem for us, and it will give us more works...
> 
> So creating a repo kdav2 seems to be a good idea, so a day when a
> maintainer will decide to evaluate kdav2 + kdepim we will be able to port it.
> 
> But actually I think it's not safe to accept your patch.
> 
> Perhaps in the future if there is more autotests, more testcases etc we
> can re-evaluate the situation.
> 
> But I am not sure that Dan or me we want to debug future problem in kdav 
> resource.
> 

That works for me.

Unless someone disagrees sometime soon then I'd create a KDav2 following
the same model of KIMAP2.
KDAV2 would be completely coinstallable to KDAV and I'd maintain it,
allowing you to keep using KDav for as long as you need,
and allowing me to do what I want to.

Sandro, Daniel, please let me know if you'd prefer a different solution.

Cheers,
Christian