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