[Ietf-caldav] polling

[Helge Hess]

On Aug 17, 2004, at 18:33, Dan Winship wrote:
> (The exact problem that the following protocol is trying to solve is
> "make it possible for a client to find out about all modifications to,
> additions to, and deletions from a collection since an arbitrary time 
> in
> the past, without requiring the server to keep an unbounded amount of
> historical data or per-client state".)

OK, read the approach, clever idea! :-)

I have some issues with that though (well, actually I notice that this 
is indeed some kind of server author vs client author thing as well 
;-):

modtime
=======
This simply can't work?! You cannot base a synchronisation decision on 
a modification time which is kept in a 1s or less granularity. If only 
two people do a Palm sync to a shared folder in some overlapping time 
(9:00 AM at the office) this is bound to break (given that we can 
handle at least something between 10-100 changes per second).
In addition modtimes are broken because they require the client and 
server to be in sync.

Servers
=======
You expect servers to change the data model for CalDAV. This won't make 
people happy ;-) If this really needs to be done at the server, I 
prefer to have a different service for that. Actually I think this is 
what SyncML might already cover (with per client state though).


So back to server vs client, to solve (changes marked with _):
"make it possible for a client to find out about all modifications to, 
additions to, and deletions from a collection since _the last sync_, 
without requiring the _client_ to keep an unbounded amount of 
historical data or per-client state, _and without requiring any changes 
on servers_".

IMHO this is well covered by both, iCalendar and WebDAV. The client 
needs to manage a snapshot of the last sync with its cache to ensure 
its validity. Doing this is pretty trivial, either:
a) select the uid + iCal sequence
or
b) select the resource + etag
I think tracking server changes this way is really reasonable for 
client authors (just keep the hrefs/etags the cache is based on with 
the cache).

Compatibility with servers which cannot track an object version is also 
easy to solve. They can simply use the moddate timestamp (utime or 
seconds since 2000 or whatever) as the version, this will give them the 
maximum possible granularity in this setup.

Hm, did I miss something? ;-)

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