[Ietf-caldav] Re: Notifications [was Re: Client work]

[Helge Hess]

On Aug 16, 2004, at 22:29, Lisa Dusseault wrote:
> Interoperability could be achieved almost trivially with a trivial 
> standard but it wouldn't be very usable.

Read: iCal-over-HTTP for groupware. Agreed.

> Usability could be maximized with a complex protocol but it would be 
> only theoretical usability without good interoperability.  CalDAV is a 
> stab at a compromise there and I welcome input from this list on where 
> the balance should lie.

Excellent.

> What do you think is too complex?

I'm not entirely through thinking about all things. What comes to mind 
are:
- notifications
- reports
- fanout / iMIP
So far I made some notes on the document, I need to find the time to 
summarize and post them.

> Evidently you think DASL is not too complex but Jabber is; that's 
> interesting because it's not the same position others would 
> necessarily take, since so many XMPP /Jabber libraries exist but few 
> (none?) DASL libraries.

This is because of technology used in todays OpenSource groupware 
servers. Most are backed by a SQL database (OGo, PHPgroupware, e4l) or 
even some weird setups which use an IMAP4 server as the storage (eg 
Bynari, Kolab).

Parsing (or generating) DASL isn't hard and DASL itself maps pretty 
well to SQL. It matches the existing server infrastructure.

Notifications in contrast are "unnatural" for SQL servers, especially 
those with transaction support. To implement them, you probably need a 
separate daemon which handles that (by polling committed transactions, 
maybe with some additional trigger support).
And for a server you need to setup Jabber in _addition_. DASL is just 
an additional RPC interface to the HTTP server (like WebDAV) while 
Jabber is something completely new and requires separate 
infrastructure.

Not sure whether I was able to express my thoughts on that in 
understandable English, sorry :-| Let me know if I need to elaborate.

Note: maybe for a "Level 0" I wouldn't even enforce DASL. Maybe this is 
already "Level 1" (as required for writing thin clients). Eg servers 
like Kolab (aka Cyrus) cannot support DASL (currently) because you 
can't search arbitary attributes in IMAP4.

> Cyrus also proposed CalDAV "levels" where the first level was 
> basically what Apple does with iCal, so an even simpler "Level 0" than 
> what you propose.

Yes, might make sense. Though I'm not sure why this would be called 
"DAV", because its just regular HTTP.

> The reason ACL is a requirement in CalDAV is because the requirements 
> investigation that the CalSch WG did resulted in deciding that access 
> control was a requirement for a calendar access protocol.   I don't 
> think it's actually a requirement, but I'd like some kind of rough 
> consensus before making it optional.

This is something I need to think about. I guess this should be a level 
feature. We currently have no ACL support, but I guess it shouldn't be 
hard nor time consuming.

Eg in our Outlook plugin the user currently has not possibility to 
configure permissions. If he tries to write an readonly appointment, 
the server will issue a HTTP 403 and Outlook will give the user the 
option to either throw away the changes or save the appointment in some 
other folder.
Apparently this is OK for our customers ;-), so I would assume that 
this isn't a required feature for clients.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org