[Ietf-caldav] Re: Notifications [was Re: Client work]
helge.hess at opengroupware.org
Mon Aug 16 13:27:21 PDT 2004
On Aug 16, 2004, at 17:42, Dan Winship wrote:
>> Personally my goal is to bring as many _available_ servers and clients
> With how much work on the servers?
For "level 0" applications only with the work required to implement the
protocol. No functional additions should be necessary.
Do "we" write a design document on how the "perfect" server looks like
or do we want to find a sane standard protocol which ensures
interoperability? For me the latter is the important thing and requires
special attention (eg WebDAV is pretty much focused on that, eg
rejecting things because it might break Java servlet based servers,
But as mentioned I can't tell about Lisa's motivation. It sounded a bit
like "specify how it should work, then implement if no one else does",
but I might have got that wrong. She should comment ;-)
> What will CalDAV's position towards existing servers be?
> 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])
> 2. Ignore the existing servers, force them to comply with our
> [sucks for server authors]
Certainly won't work unless there are sufficient interesting clients
implementing CalDAV which leads to chicken and egg ;-)
Few will use CalDAV if it is easier to implement a client side plugin
than to implement the protocol (see Outlook). Eg implementing an
Evolution plugin is rather easy now. Same goes for Kontact.
> 3. Support the least common denominator of functionality [sucks
Si. This is why I think protocol levels might be quite a good solution
>> Currently the only "protocol" which is more or less interoperable
>> between servers is iCal-File-over-HTTP. And this one is really
>> inappropriate for almost anything ;-)
> So assuming we're targeting a higher level of functionality than iCal-
> file-over-HTTP, what functionality would that be?
Being pragmatic for now I'm mostly interested in a Level 0 which would
- each iCal resource an individual HTTP resource
- therefore proper locking etc
- queries using DASL
- maybe ACL support
I know that this isn't perfect, but already makes calendaring
interoperability 1000% better from what it is now.
Then we can work on additions to add things like fanout or reports.
> It seems to me like there are two big things you can do with a real
> calendar server that you can't do well with just iCal-over-HTTP: thin
> clients, and shared access to calendars (eg, public folders, accessing
> other users' calendars / them accessing your calendar, direct booking
> resource calendars, etc).
The latter is the more important thing, shared access. At least I am
talking about groupware here, not about PIM, and this implies shared
> 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 ;-)
Polling is a simple DASL query (like you do in your Exchange connector
SELECT uid,sequence FROM /users/dan/Calendar;
SELECT uid,etag FROM /users/dan/Calendar;
since uid and sequence are promoted from the iCal. I think this works
fine for 90% of the cases.
"Real" notifications would require a separate event service (and state
handler for that) on the server and a lot of systems won't add this
(probably impossible in practice with a PHP or Servlet centric
Notably version-set snapshots really belong on the client/device, since
they are cache specific.
>> To summarize: my _strong_ fear is that if CalDAV ends up being too
>> complex, few will implement it. The mentioned notification is
>> one thing which would require a major amount of work in existing
>> servers (including OGo and PHPgroupware).
> Are you worried about jabber-based notifications specifically, or
> notifications/polling in general?
a) I think if we specify notifications, we definitely should go with
b) yes, I'm worried about notifications, because they imply major
on existing servers
c) polling should be no problem if it is stateless as in the example
BTW: OGo would probably implement Jabber notifications, but this would
be an optional component and makes setup more difficult. Also while we
are positive on this, it would nevertheless be quite an amount of work
(means: takes a lot of time unless we find a sponsor for that ;-).
More information about the Ietf-caldav