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

[Helge Hess]

On Aug 16, 2004, at 17:42, Dan Winship wrote:
>> Personally my goal is to bring as many _available_ servers and clients
>> together
> 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, 
sigh).
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?

Hopefully interoperability.

>      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 
> model
>         [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 
> for
>         everyone]

Si. This is why I think protocol levels might be quite a good solution 
for that.

>> 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 
be just:
- 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 
> of
> 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 
folders.

> 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;
or maybe
   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 
solution).

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 
>> certainly
>> 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 
Jabber
b) yes, I'm worried about notifications, because they imply major 
additions
    on existing servers
c) polling should be no problem if it is stateless as in the example 
above

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 ;-).

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