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

[Dan Winship]

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
enough. :-)

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
tomorrow.

-- Dan