[GroupDAV] GroupDAV vs. CalDAV

[Adam Tauno Williams]

--=-+68ZC0vnRI5xCb5utkEp
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> ... please not again ;-)

Didn't mean to start 'a thing'.

> Julian: since when does the _age_ of a draft matter? ;-) And what a =20
> 'viable alternative' is depends on the specific goals/needs.
> Adam: From an implementers POV GroupDAV can be a "replacement" for =20
> CalDAV - if you are fine with the facilities it provides. Obviously =20
> the GroupDAV draft is not a generic replacement for the CalDAV RFC =20
> (which of course was your initial point).

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.

> People should take care about the context when they talk about =20
> 'GroupDAV'. Its easy to end up in flame wars otherwise. Is it an =20
> implementation, is it the draft, is it the overall project etc.
> Anyways, since the goal is being 'pragmatic' maybe its time to re-=20
> evaluate the position of GroupDAV in the current environment. I think =20
> the situation has changed a bit, with CalDAV released as an RFC, =20
> getting implemented by Mozilla and Apple, and CardDAV being in the =20
> works.
>  From a (desktop) clients point of view CalDAV vs GroupDAV doesn't =20
> matter that much since the more advanced CalDAV features are all =20
> client initiated.

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.  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.  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=3D1099
Otherwise the UI is 'dumb' and seems to permit modifications that then
fail with an error [ or fail with no error! :) ];  this creates users
who think the system is broken.  Maybe other people's users are more
tolerant than mine.

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

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.

But I've ended up creating my own solutions so allot of this is academic
to me.  However I would like to see 'generic' clients work better as
some users very much like them.   Funambol is my only real use of
GroupDAV at this point.

>  From a servers point of view, especially for legacy ones, GroupDAV =20
> 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.

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

Yep,  I think that is pretty clearly what is going to happen.  No
surprise;  look at the number of applications that "support" LDAP but
don't chase referrals or dereferance aliases or that "support" Kerberos
but go all monkey-poo when they see a post-dated ticket.  Ugh.  Funny
how the Open Source crowd raves about open standards and then piddles
all over them.   Sorry.... it is hard not to rant. ;)

> The client situation isn't *that* much better for CalDAV, the =20
> interesting CalDAV clients are iCal.app and Sunbird (AFAIK no non-=20
> alpha Kontact or Evo connectors).

Yep, all pretty dodgy.

> I think we probably won't get Apple to make iCal.app support GroupDAV =20
> directly. Adding GroupDAV support to Sunbird should be an option =20
> (after all we already have the contact extension).
> Also interesting is that none of the big vendors seem to care about =20
> either ;-) Even Google does its own proprietary stuff.

There is a legitimate argument that most of these standards force
least-common-denominator behavior.  From a solution providers
perspective if using standard A means my client can't do/support/use
features X, Y, or Z, then...  And when 'the standards' try to compensate
by being thorough, like CalDAV, then everyone complains about how
complicated the standard is.  Thus, people just roll-their-own. =20

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

--=-+68ZC0vnRI5xCb5utkEp
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBGk4KLLRePpNle04MRAtR2AJ4r1689B9Y9DbLdjic9Vgep1ahJvQCffDAq
ICxSvsk/mpg+5EcnflQeFTg=
=wBmi
-----END PGP SIGNATURE-----

--=-+68ZC0vnRI5xCb5utkEp--