[Kde-pim] CalDav / CardDav support (Was: Re: Marketing blocker collection, DEADLINE: 2013-03-10)

[Grégory Oestreicher]

Le Mercredi 20 Mars 2013 22:39 CET, "Georg C. F. Greve" <greve at kolabsys.com> a écrit: 

> A full server would provide capabilities of addressing the different 
> vendor flavours of CalDAV/CardDAV in existence and map them to an actual 
> canonical storage format, which CalDAV/CardDAV is not.

CalDav and CardDav are not storage formats, they're protocols to exchange PIM data and are defined in RFCs, so a server or a client don't need to know different vendor flavours. It only needs to respect the RFCs and stick to it. Admittedly this is in a ideal world, and some clients or servers have different ways to interpret the RFCs, which lead to some issues, but there shouldn't be any workarounds for specific implementations, protocol-wise, in a server or a client.

> Otherwise there 
> is a good chance that a fully standards compliant implementation in the 
> Akonadi server and a fully standards compliant implementation on 
> ownCloud would still have problems exchanging data.

Nope, and that's the whole point of being RFC-compliant. If you support 100% of the concerned RFCs you can talk to a peer that does too. Then I'm not saying that the resource complies with all RFCs as it does not implement everything, but it tries to be compliant with the implemented subset.

> Google will allow you to find plenty of instances of multi-client 
> CalDAV/CardDAV setups having compatibility issues, e.g. for Zimbra. So 
> even full groupware servers (which ownCloud is not) struggle with this. 

That's mostly due to either a bad interpretation of the RFCs (which happened to the resource too) or a lack of support for some optional sections of those that the client or the server decides to rely upon. In this case one of the peers is not 100% RFCs compliant, or the other is more compliant and don't degrade gracefully.

> I'm not sure this is what is actually happening, but it is entirely 
> possible the problem is not actually with the Akonadi agent and that it 
> correctly reports invalid data, while ownCloud and the CalDAV client 
> you're using on Android happen to understand each other well enough that 
> you got lucky.

Or they have a better support of applicable RFCs, or they're not constrained by the limitations imposed by Akonadi. On the first point only a capture of the exchanges between the resource and the server would help debug this effectively. On the second point Akonadi should provide a way to be less agnostic with regards to the items stored and know a bit more about what's requested. I'm thinking in particular that Akonadi should provide a way to limit the range of events that are asked to the resource.

> Either way: Supporting dumb CalDAV/CardDAV stores is a bit outside the 
> scope of Akonadi, I guess, as it would mean that it would have to have 
> compatibility provisions for every single client out there, which should 
> normally be handled by the server.

See above, but the resource should support all available servers that are RFC compliant. However I don't want to add workarounds or ugly hacks for the ones that fails to implement the standard.

> That means this would be a feature 
> request, and while a lacking feature of course results in "could be 
> better" user experience from the user perspective, it is not in and of 
> itself a usability issue.
 
I think that having your CPU thrashed by incessant back and forth between the resource and akonadi is indeed a usability issue. I'm willing to help on this but I need someone who's ready to test and spend some time providing answers.

Cheers,
Grégory
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/