[Design] RSS in Cosmo for event change notification

[Alec Flett]

Mitchell Kapor wrote:
> I propose we seriously look into developing a notification capability 
> in Cosmo 0.4.  The main use case to be supported is notification of 
> recent event changes via an RSS feed of a calendar published on Cosmo.
>

I like the idea of being notified for specific items that have changed, 
but I wonder if we could provide notification within Chandler as well.. 
in fact I wonder if we could use it as an inexpensive way to know when 
to initiate a 'pull' from Chandler?

i.e. if it is cheap to do an http GET of an RSS feed, maybe we can kick 
off a background sync when the RSS feed has changed? (though in an ideal 
world, a PROPFIND would be as cheap as a GET so we could just keep 
'pinging' cosmo by repeated PROPFINDs)

I also wonder if the dashboard can simply show newly synced events 
somewhere - either to be triaged, or in some already-triaged place.

Alec
> This is of particular use when a calendar has a reader who is NOT the 
> writer of events, e.g., Esther keeps my calendar and adds appointments 
> to it.  As it now stands, if I want to be sure whether an appointment 
> has been finalized I either have to look through future weeks or ask 
> Esther.  Neither of these methods are very efficient.  It would be 
> easier if I simply received a notification that my calendar had 
> changed.  Then I would know for sure.
>
> 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.
>
> My expectation is that this would be good enough to make it worthwhile 
> to use any RSS reader to subscribe to this feed.  New changes would 
> show up as unread items.  It's as simple as that.
>
> One virtue of this approach is that it allows us to add useful 
> functionality to the overall Chandler system at a rate more like the 
> speed of web development and less like the usual rate of Chandler 
> client development itself (which is slow because it's the nature of 
> the beast).
>
> Extended functionality:  The RSS reader is Chandler could be brought 
> to a point of usefulness that it could be used rather than an external 
> RSS readers.  This would be nice, but it is not necessary.  Or could 
> happen later.
>
> There could be user control of the number of days of recent changes to 
> be kept in the feed.  Again, nice but not necessary.
>
> Another nice-to-have would be the ability to click on a link in the 
> body of the feed item and be taken to the detail view of that event in 
> Chandler (or Scooby).
>
> Question:
>
> Is it easy to develop a feed that somehow distinguishes between 
> additions, modifications, and deletions?
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design