[Chandler-dev] Recurrence and changes to masters in the dashboard

[Grant Baillie]

Howdy, Bryan and Jeffrey: Thanks for your postings. To start out  
with, a general question for the masses:

How specifically does the Table currently know when to redisplay items?

More inline below in Bryan's message,

--Grant


On 26 Jan, 2007, at 09:14, Bryan Stearns wrote:

> Jeffrey,
>
> If the only attribute we're setting on the master that we should be  
> setting on the occurrences, we could do either of these things:

Hmm... I've re-read the first clause of this sentence a couple of  
times, and I still don't understand it :(. Did you mean "... we  
should be setting on the occurrences is 'read'"?

> - Observe 'read', and if it's set on a recurrence master, propagate  
> the setting to all the occurrences when the observer fires

It seems to me that the repository should propagate notifications(*)  
of inherited values; i.e. if I change x on the master, I should get  
notifications for each occurrence that doesn't have its own value for  
x: since effectively those values are changing, too. Note that this  
is an issue not just for "read", but any attribute that contributes  
to the display of the summary table.

[[(*) I'm intentionally being lazy with the word "notification" here;  
really I mean any notification of changes (i.e. watchers/monitors/ 
notifications)]]

Essentially, what I'm saying is that the first pass at the  
"inheritFrom/inheritTo" has the API in a inconsistent state: the  
repository takes care of getattr() inheritance, which is what we care  
about in an object model. However, other repository features  
(e.g.RepositoryView.findValues(), collection reindexing,  
notifications), are completely unaware. For findValue(s): we have a  
higher-level, but completely parallel API that does the extra lookups  
in the case where attributes are inherited. Are there ever cases  
where you would not want inheritance to be followed?

> - Special-case recurrence masters in the code that sets the 'read'  
> flag, and manually propagate the setting to all the occurrences if  
> the target is a recurrence master.
>
> (I prefer the latter: While it couples tighter, it seems lighter- 
> weight than the former)

There are costs associated with adding redundant attribute values to  
the repository, and also with maintaining them correctly.

> Jeffrey Harris wrote:
>> Hi Folks,
>>
>> I'm working on bug 6702, "Clicking on recurring events in the  
>> dashboard
>> doesn't mark them read".
>>
>> In fact, the events do get marked read, but it's their master event
>> that's marked read (so read/unread applies to all occurrences).   
>> This is
>> the desired behavior.
>>
>> The problem is that changes to masters doesn't cause notifications to
>> fire in the table.  I wanted to start a conversation on the list  
>> about
>> how best to remedy this.
>>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev