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