[Ietf-caldav] polling

[Dan Winship]

On Tue, 2004-08-17 at 23:32 +0200, Helge Hess wrote: 
> 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.

I used 1-minute granularity in the example because I didn't want to
write out longer timestamps. :-) I was assuming they would in reality be
much more granular than that.

> In addition modtimes are broken because they require the client and 
> server to be in sync.

Not really. The poll response just needs to include the current server
time, and the client remembers that value until the next time it polls.
(It doesn't even need to be in a form that the client can parse. It
could be specified as just an opaque cookie of some sort.)

> Servers
> =======
> You expect servers to change the data model for CalDAV. This won't make 
> people happy ;-)

You expect to be able to be able to support the Next Great Thing without
changing any code? :-)

> 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_,

Well... I suppose that's actually what I meant.

> , _and without requiring any changes on servers_".

"Besides that they support CalDAV" :)

> 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
> orAt any rate
> b) select the resource + etag

Well, sure, this is what the Evo Exchange Connector does now, but it
sucks if you have a huge calendar, because it has to pull the complete
list of UIDs over the network every time.


FWIW, a completely modtime-unaware server could implement the poll
report like this:

        4 objects in collection
        
        Modified/Added uids:
          306A
          9294
          53A1
          99BB
        
        Removed objects before:
          seq 1, uid 306A
          seq 2, uid 9294
          seq 3, uid 53A1
          seq 4, uid 99BB

ie, ignore the client-provided timestamp entirely and just send the
complete list of objects in the response. The modified/added part would
force the client to re-fetch every object, and the removed part would
force it to discard any object that wasn't in that list, and you'd end
up synced, just not as efficiently as in the case where the server was
keeping track of the extra info. (By adding etags or whatever to the
first part, we could also let the client avoid re-fetching any objects
that hadn't actually changed from its cache.)

-- Dan