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

[Helge Hess]

On Aug 16, 2004, at 23:22, Dan Winship wrote:
> 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. :)

OK, I see ;-)

> (Though dealing with N protocol levels is a lot nicer than dealing with
> 2^N combinations of capabilities.)

Yes, it needs to be coarse grained enough.

To pickup Lisa's example of ACLs I thought about something like this: 
query the server whether it supports an ACL on a collection, if so, 
show the Evolution folder permission dialog, otherwise hide it from the 
menu (same thing on resources).
This is a simple check and probably not too much work for you as a 
client developer ;-) Of course it might be hard to define proper 
"units".

As another example a thin client might require a server supporting 
level 1 (DASL for range queries like in a week overview) or level 2 
(complex reports) and refuse work otherwise, while a native client 
probably works with level 0 by caching all information locally and 
search there.
This example matches on how IMAP4 is used. (eg the OGo IMAP4 web client 
needs bodystructure and server side sorting to work with acceptable 
speed while Mail.app doesn't care, caching everything locally).

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

Exchange can probably consider industry standard and as you know 
notifications do not work reliably with that, forcing you to poll. QED 
;-)

I do not agree with you the point on the "live" view. This is more a 
problem for the users with sync solutions vs live solutions, not 
whether native or web.

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

Because you do not support F5! ;-)

How often to you currently poll in the connector? Is this just a 
problem because polling is expensive in Exchange or would it be a 
problem as well if you would poll every minute (or 30s, which would 
give you about 300-1000 concurrent users on a single server)?

> But that could just be an argument for "notifications need to be
> possible", not "notifications need to be mandatory".

Exactly. Also easy for the client. Poll every 5 minutes in any case, if 
you get a notification, you get a "more live" view, if you don't, well 
it still works :-)

> I have some thoughts on a "polling for changes" REPORT that I'll post
> tomorrow.

This REPORT thing is something I did not understand yet. Eg for cyclic 
appointments I would prefer a DASL query + a HTTP header (comparable to 
'brief') or a special resource. But I need to look into that.

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