[Design] RSS in Cosmo for event change notification

[Ted Leung]

On Apr 10, 2006, at 5:03 PM, Mimi Yin wrote:

> It might also be nice if Chandler items could display when they've  
> been edited and by whom. So I can go to a list view of the Office  
> calendar and see all the recently added/edited items at the top,  
> like new, unread email.

If you look in the domain model, there are actually (unused)  
attributes for recording this information.   One of my goals for the  
0.7 domain model work is to get these "turned on", since this kind of  
metadata is useful for all sorts of things.

>
> On Apr 10, 2006, at 3:43 PM, 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.
>>
>> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

----
Ted Leung                 Open Source Applications Foundation (OSAF)