hey, that worked yo amazing hiya So, I'm working on bug 6702 no soup :) I thought I was done, but I realized I hadn't read the spec right basically, getting read/unread working on recurring events anyway, to make a long story short, it's desired that read/unread for recurring events apply to "all events that look the same (modulo recurrence-id matching dtstart) but I lobbied for trying "read/unread/needs reply apply to all occurrences" so that says it's stored on the master? which is much easier well, in the end, yes, the "look the same" bit would've been a little complicated not impossible, just not the place to start so anyway, in the final analysis, what I'm trying to implement is read/unread/needs reply apply to all occurrences and the nicest way to do that is to make changes only apply to the master, never occurrences so that's working fine, no sweat what about modifications? making a change to the master changes everybody now that attributes are inherited for now, modifications, too the problem is that when a change is applied to master and it's inherited by lots of occurrences that change doesn't result in UI updates -->| reid[osaf] (n=rae@tnir.org) has joined #recurrence * reid[osaf] is eavesdropping if that's ok Totally OK, want a summary? Here, I'll pastebin what I've said so far k http://pastebin.ca/278156 are you talking about the dashboard, or other UI? If attributes are inherited, it seems like a mechanism is needed to distribute notifications... I'm still osmosing Chandler's "item" architecture just the dashboard in this case, gbaillie understood, reid[osaf], happy to apply pressure to increase the speed of osmosis :) stearns, agreed so, we're back to the same indexing problem as before. yes or alternately I could set the attribute individually on all modifications, that would work fine, too. But it's inelegant ya So, I'm wondering if this is a "gbaillie will solve it, no worries" kind of thing or a "there aren't many situations like this, special case it for now" well, there will be more cases like this. (in which case stearns should be involved in the discussion, I thought) yeah, I figure so. well, isn't this an issue for all changes that the occurrences inherit? yup (and not just for display -- for indexing, too) OK, so, maybe this is, like gbaillie said, an identical issue to the indexing inheritance issue, so I should just not worry? -->| bear (n=bear@c-71-230-109-9.hsd1.pa.comcast.net) has joined #recurrence well, it's more than the indexing issue. -->| soup (n=soup@kumu.osafoundation.org) has joined #recurrence b/c the live objects in the dashboard need to update, too. whoa, a soup * JeffreyH points bear at http://pastebin.ca/278170 if he'd like the notes so far nope - just playing soup wrangler :) I think that's called a "ladle". bear == ladle, ha big dipper? oh my woah * reid[osaf] loves astronomy humour hehehe Yeah the in-play objects do complicate matters. Maybe the solution to both is to propagate item change notifications to all occurrences? so, we may need a repo API for "attribute x of uuid y changed" should we invite andi? yeah seems like a recipe for way too many notifications