[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    [Kde-pim] CalDav / CardDav support (Was: Re: Marketing blocker collection, DEADLINE: 2013-03-10)
From:       Grégory_Oestreicher <greg () kamago ! net>
Date:       2013-03-21 7:48:10
Message-ID: 2aa2-514abb00-7-a70dcd0 () 250612550
[Download RAW message or body]

Le Mercredi 20 Mars 2013 22:39 CET, "Georg C. F. Greve" <greve@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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


[prev in list] [next in list] [prev in thread] [next in thread]