Talk track filtering

[conseo]

Hey Mike,

> 
> > Wouldn't it be easier to handle all this that when I call
> > Stage.i().setDifference(someKey)? I feel a bit lost how this belongs
> > in the TalkTrack. I guess what we need is some kind of
> > difference-key parser deciding how to react on staging new
> > differences, no matter who is staging them, but depending on
> > context. It needs to know both mailish-user names, aUser and bUser,
> > of the difference to compare them to the stage actors and decide its
> > own "selectand".
> 
> Let's wait and see if there are problems.  Aside from the filtering
> patterns we already agreed to, and common staging conventions (don't
> stage unless you provide an un-stager) there are no requirements for
> the talk track as yet.  It should all work together (more or less) no
> matter how you stage your diffs, or react to diffs staged by others.
> It should be robust.
> 
Ok, I need to look into how I react on a new difference staged. I guess I 
should:
1. Light all messages related to that difference, (will implement later)
2. deselect the message item in the talk track and set a default EMPTY message 
on stage if the message still fits the talk-track selection. (this is not very 
clean) (?) Maybe we should model the state changes of the stage and define how 
each track responds to each stage state transition?

Roadmap proposal

I still also need to look into how to select all messages of a tree (which 
btw. would benefit from historical data, because old messages can get lost on 
vote shifts). How to prioritize to get a usable version of the talk-track 
quickly? I think having clear state transition definition and code is 
mandatory, everything else can come later. Second I need to add talk lighting 
to make the track useful and finally the voting history likely has to be 
solved when I need to join the voting tables with the message tables to find 
all messages of a tree, so this would be third.

conseo