[Ietf-caldav] polling

[Lisa Dusseault]

I think Dan's right, in that the problems with timestamps can be 
resolved if everything is determined by the server's timestamp.  The 
server has a responsibility to keep a consistent clock, where time 
moves forward and not backwards.   The server provides Last-Modified 
headers already for resources.  The server must respond to any HTTP 
request with the Date: header so the client always knows what the 
server considered the time to be, when the last request was made.  So 
all the client has to do is remember the server's timestamp when it 
last synchronized, and ask the server for changes since that timestamp.

But this all only applies to a theoretical feature to make 
synchronization perform better -- synchronization is already quite 
possible with ETags, albeit not as efficient as it might be.  I don't 
consider high-perf synchronization to be a requirement for base CalDAV.

That would alleviate the concern that this materially changes the data 
model for CalDAV from the current WebDAV model.

Lisa

On Aug 18, 2004, at 7:09 AM, Dan Winship wrote:

> 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
>
>
> _______________________________________________
> Ietf-caldav mailing list
> Ietf-caldav at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav