[Ietf-caldav] Re: RSS for calendar exchange /polling / etc.

[TimHare at comcast.net]

As I understand RSS readers, RSS is essentially a polling operation: check 
for updates to the feed every so often = polling in my book.

I think the tombstone idea is pretty do-able;  I don't know the length of 
the UID, but assuming a 20 bye UID and a 4 byte binary timestamp to track 
when it was deleted  we could store an awful lot of tombstones. I don't 
think Calendar items/changes reach the volume of e-mail items in a 
comparable IMAP system. I don't have statistics, if anyone does please 
share them, but a rough guess of what happens at work is that the number of 
Calendar invitations/changes I receive per day is an order of magnitude 
smaller than the number of e-mail messages.

Here's possibly a compromise idea?  (again remembering that I haven't 
completely read the DAV spec).  A client that wants to only check once in a 
while does nothing. A client that wants to be more up-to-date sends a 
subscription request, for lack of a better term, naming the collection,  to 
the server. When there are updates to a collection, the server sends a 
notification message to the subscribers, who then check for the updates. 
This keeps total message volume down: some clients check when they want, 
which hopefully is not super-frequent; those that need notification get a 
short fast message telling them when to do the more complex work of looking 
for the changes.

Tim Hare,
Interested Bystander, Non-Inc.