[Ietf-caldav] Re: Notifications [was Re: Client work]
danw at novell.com
Mon Aug 16 14:22:50 PDT 2004
On Mon, 2004-08-16 at 22:27 +0200, Helge Hess wrote:
> > 1. Have protocol levels / Capability strings (eg, CalDAV Server A
> > allows appointments to recur forever, but CalDAV Server B
> > doesn't). [sucks for client authors]
> I think this can be solved by HTTP error codes. (I would also be
> interested in the exact case where this hits the client, some servers
> might "flatten" the cycle [client push would require a client fetch and
> loose the cycle info])
I didn't mean that specific case sucks for clients, I meant the general
case sucks. The more ways the server can vary, the more stuff the client
has to be able to deal with. This way lies IMAP. :)
(Though dealing with N protocol levels is a lot nicer than dealing with
2^N combinations of capabilities.)
> > And if you're going to have multiple people accessing the same
> > calendars, then clients need to know when someone else changes
> > something in one of them. Ideally that means notifications.
> > At a minimum you need good polling support.
> Well, you somehow imply that calendaring doesn't work in current
> servers because they don't have notifications ;-)
The proprietary client/server combinations do have notifications, and
the web-based systems don't need notifications because there's generally
less of an expectation of having a completely live view.
> Polling is a simple DASL query (like you do in your Exchange connector
And we get lots of complaints that the views don't update fast
But that could just be an argument for "notifications need to be
possible", not "notifications need to be mandatory".
I have some thoughts on a "polling for changes" REPORT that I'll post
More information about the Ietf-caldav