[GroupDAV] GroupDAV vs. CalDAV

Helge Hess groupdav@opengroupware.org
Tue, 10 Jul 2007 12:02:42 +0200


... please not again ;-)

Art: there *is* an official position of the authors (ups, thats  
me ;-) on the relationship to CalDAV. Its even in the FAQ. Opinions  
of implementers are their own, thanks ;-)

Julian: since when does the _age_ of a draft matter? ;-) And what a  
'viable alternative' is depends on the specific goals/needs.

Adam: From an implementers POV GroupDAV can be a "replacement" for  
CalDAV - if you are fine with the facilities it provides. Obviously  
the GroupDAV draft is not a generic replacement for the CalDAV RFC  
(which of course was your initial point).

People should take care about the context when they talk about  
'GroupDAV'. Its easy to end up in flame wars otherwise. Is it an  
implementation, is it the draft, is it the overall project etc.


Anyways, since the goal is being 'pragmatic' maybe its time to re- 
evaluate the position of GroupDAV in the current environment. I think  
the situation has changed a bit, with CalDAV released as an RFC,  
getting implemented by Mozilla and Apple, and CardDAV being in the  
works.

 From a (desktop) clients point of view CalDAV vs GroupDAV doesn't  
matter that much since the more advanced CalDAV features are all  
client initiated.

 From a servers point of view, especially for legacy ones, GroupDAV  
is *much* easier to implement.
But implementing the necessary subset of CalDAV to please desktop  
clients is not _that_ hard either. Its only hard if you actually want  
to implement the standard :-)


So I suppose what will happen is that plenty of servers will work  
with specific Sunbird or iCal.app versions, implementing just the  
CalDAV subset required to drive those. And they will label themselves  
'CalDAV' servers, because they can talk to those specific CalDAV  
clients.

Now that CalDAV subset should be pretty close to what is provided by  
GroupDAV. I wonder whether it would be the 'pragmatic way' to write  
down GroupDAV 2.0 as a 'best practice' of this CalDAV subset?
I guess it will be GroupDAV-now plus 2 or 3 specific REPORTs. Other  
clients and servers could then use the subset as a basis to get started.

I'm not sure. GroupDAV _is_ much simpler to implement in servers,  
even when we just consider reduced CalDAV. On the other side GroupDAV  
isn't that widely implemented in servers either. Though the latter is  
mostly because we did not really finish the goal yet of having great  
clients (the KDE plugin doesn't work sufficiently well, the Evolution  
plugin is OK but not 100% GroupDAV and we only have an AB plugin for  
Mozilla).
The client situation isn't *that* much better for CalDAV, the  
interesting CalDAV clients are iCal.app and Sunbird (AFAIK no non- 
alpha Kontact or Evo connectors).
I think we probably won't get Apple to make iCal.app support GroupDAV  
directly. Adding GroupDAV support to Sunbird should be an option  
(after all we already have the contact extension).

Also interesting is that none of the big vendors seem to care about  
either ;-) Even Google does its own proprietary stuff.


So the direction is not entirely clear. I suppose we should wait a  
bit longer and see what happens with CalDAV/CardDAV.

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/