[GroupDAV] GroupDAV vs. CalDAV

[Helge Hess]

On 10.07.2007, at 14:58, Adam Tauno Williams wrote:
> Yep, that is all I meant.  Several things are possible with CalDAV  
> that
> aren't with GroupDAV; thus I think calling it [generically] a
> replacement is at least confusing.

Yes.

> For me the principle problem with GroupDAV [aside from the shaky state
> of the current clients] are -
>
> Permissions: For CalDAV there is "A CalDAV server MUST support the
> WebDAV ACLs standard [7]"  In an enterprise context [at least ours :)]
> operating without anyway to set/get permissions is a pretty serious
> drawback.

Nothing prevents a GroupDAV server from supporting WebDAV ACLs? (or  
any other WebDAV or HTTP extension). The client can easily discover  
whether WebDAV ACLs are supported and then provide a UI (or not).
[same for locking, BTW]

This has not that much to do with GroupDAV.

> The folder model of permissions can work, and works better
> with recent fixes to ZideStore (this is in relation to OGo) but is  
> still rather limited / cumbersome.

Specific to the OGo implementation of GroupDAV. This has nothing to  
do with the *GroupDAV* draft.

It would be nice to enhance ZideStore to support WebDAV ACLs.

> Just the ability to know that a given
> appointment cannot be modified would be sufficient for most  
> situations.
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1099

Yes, that would be very useful and simple enough for GroupDAV.

> Of course I haven't seen a CalDAV client that implements this, so....
> whatever. :)

Precisely ;-)


> Performance:  With lots of data and no bulk get method GroupDAV over a
> WAN isn't stellar, especially if you have LOTS of data.  Thousands of
> individual requests also hurt the server.   The client having to
> basically pull all available data and do a local search is a pretty
> serious limitation;  and the state of local clients is that they *ALL*
> fail when presented with thousands of contacts.  But I accept that
> GroupDAV may simply not be suitable for this situation.

I really don't buy this argument. The many GETs are only necessary at  
the initial cache fill, which is usually performed in the LAN and can  
use a persistent HTTP connection.
Afterwards its only the etag PROPFIND which is quite efficient and  
works for tens of thousands of entries with (assuming proper content  
compression).

A multi-GET might be quite useful, but its quite a complication of  
the protocol (especially because its neither in HTTP nor in WebDAV)  
and is IMHO not strictly necessary in the real-world (because its a  
one-time operation).
Well, an MGET would give a huge speed-up for database based servers  
like OGo. Maybe it _is_ worth adding, probably.

The targetted clients needs to pull all the items for offline  
capability anyways. The searches must be implemented in the client  
anyways due to this.
In fact thats a basic assumption of GroupDAV. Supporting serverside  
queries is a useless complication because the client has to do it  
anyways for offline operation.


> However I would like to see 'generic' clients work better as
> some users very much like them.

The problem is that 'generic' quickly ends when you work with  
permissions ...


>>  From a servers point of view, especially for legacy ones, GroupDAV
>> is *much* easier to implement.
> Agree,  GroupDAV (at least for basic get/put) is really really easy.
> Doing the client side cache correctly/efficiently seems to be a major
> problem with all current clients.  But this really isn't a failing of
> GroupDAV.

Exactly. A CalDAV client (with offline capability) would need to  
exactly the same.
And writing the cache is *really* no rocket science but almost  
trivial (its just keying the content on URL+etag?!). Not sure why  
(whether) the clients would have issues with that.

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