[Ietf-caldav] Re: Notifications [was Re: Client work]
helge.hess at opengroupware.org
Mon Aug 16 14:18:31 PDT 2004
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.
> What do you think is too complex?
I'm not entirely through thinking about all things. What comes to mind
- 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
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
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
Apparently this is OK for our customers ;-), so I would assume that
this isn't a required feature for clients.
More information about the Ietf-caldav