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

[Bryan Stearns]

Hi Grant - see inline..

Grant Baillie wrote:
> 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?
It gets a collection notification (that an item in the collection being 
displayed has changed).
>
> 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'"?
Yep - that's what I get for hitting reply before the coffee machine has 
beeped to indicate that the elixir of clear and rational thought is ready.
>
>> - 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)]]
That sounds much better. Just propagating the notification makes sense, 
especially if this lets us avoid storing the propagated values as I'd 
suggested, which doesn't make sense in hindsight, for the reason Grant 
gives:
> There are costs associated with adding redundant attribute values to 
> the repository, and also with maintaining them correctly.