[Design] RSS in Cosmo for event change notification

[Brian Moseley]

On 4/10/06, Mitchell Kapor <mitch at osafoundation.org> wrote:

> Cosmo already has RSS support in 0.3.  The trick now is to make it
> useful with the least amount of work.  What is of interest are recent
> changes to the calendar.  It doesn't matter what the date of an event
> is, per se, but that it has been changed, i.e., added, deleted, or
> modified.
>
> If Cosmo is able to keep track via a timestamp of event changes, that
> would be the basis of the feed.  In the simplest possible useful
> implementation (which is where I think we should start), Cosmo would
> maintain an RSS feed of, say, the last 7 days of changes.

i think that cosmo's calendar feeds as implemented today address your
needs more than you might realize.

the first time you subscribe to a calendar feed, your reader will suck
down an atom item for each event on the calendar. (there's a lot of
thought to be done on how to make that more scalable for large
calendars, maybe by constraining the feed to the upcoming n weeks' of
events or something.)

then, if an event changes on the server, the next time your reader
polls the feed, it will see that the corresponding atom item has
changed.

every feed reader i've ever used (netnewswire, bloglines, feedlounge)
has been configurable to 1) hide previously viewed items and 2)
re-display previously viewed items that have changed since they've
last been viewed.

while i haven't specifically verified that any of these readers
behaves exactly this way with a cosmo calendar feed, i have other apps
that emit feeds, and i have seen the exact behavior you're looking
for, without the server having to deliver a feed of changed items.

this probably breaks down when events are removed from the calendar. i
don't recall any clients having options for alerting you when an item
has been removed from a feed. but we could of course build such a
thing into chandler.

in general, i think it's preferable to let clients do as much decision
making in this area as possible.

> Is it easy to develop a feed that somehow distinguishes between
> additions, modifications, and deletions?

it would require an extension to the atom specification but wouldn't
be particularly difficult. however, it's easy enough for a client to
recognize all of these cases given the information that cosmo feeds
already include.