[Design] What does Read/Unread status mean in Chandler?

[Mimi Yin]

We had a follow-up meeting today to finish going over: http:// 
wiki.osafoundation.org/bin/view/Journal/ 
DashboardSharingCommunicationsRecurrence

We got stuck on what Read/Unread status means in Chandler and in  
particular, what does it mean when it comes to recurring events?

Below is my best stab at summarizing verbally how we should treat  
Read/Unread status.

Unread:
+ Item you created in the CLI
+ Newly created item
+ Item changed by somebody else

That means, items are NOT marked as unread when...
+ An item is auto-triaged from LATER to NOW because an Alarm or Start  
date/time rolls around

In the case of a recurring event series, when an user 'Reads' an item  
or marks an item as 'Unread', we should mark all instances of the  
recurring event that look just like it. (Ignoring differences in  
Triage status and Date/time metadata.) This is true in both the  
Dashboard and the Calendar.

The reason we want to make an exception for date/time metadata is  
because we don't want users to have to mark Read/Unread status for  
each individual instance in a recurring event series.

The reason we want to make an exception for Triage status is because  
we don't want users to have to remark Read/Unread status for  
recurring events just because the event series straddles multiple  
triage status (some occurrences are happening in the future - LATER,  
1 is happening right this instant - NOW and some have already  
happened - DONE).

The fallout of this is that un-modified instances in the event series  
might have Read/Unread statuses that are different from modified  
instances.

Conveniently, this allows us to model Updates to individual instances  
in a smart way, even though for Preview, we will not be able to  
support Updates to individual instances in a recurring event series  
or the This and Future subset of a recurring event series.

Instead, recipients of Updates will receive the entire event series  
(under the hood), even if only a single instance was updated.  
However, in the Dashboard, Update recipients will ONLY see the edited  
instances at the top of their NOW section, marked as Unread. All  
other instances of the recurring event will stay put in the Dashboard  
and remain marked as Read.

So while, under the hood, we can't support edit/updates to individual  
occurrences, at the UI level, we will be able to simulate it.

This of course assumes that the above proposal is doable in the  
Preview timeframe...Jeffrey? ;o)

Mimi