Talk track filtering

[Michael Allan]

conseo said:
> 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?

That wouldn't easily scale, too brittle.  It was a deliberate design
choice to make the stage blind to the tracks.  Some suggestions:

First, don't do anything unless you must.  For example, what do you
mean by an EMPTY message?  Why is it necessary to stage it?

Second, to be sure, the stage is your selection model (I think you
agree).  "Selected" means "staged".  So just ensure the view obeys the
model and never shows something as being staged when it is not.  If in
doubt, it's always OK to show nothing as staged.  No great harm can
come of that.

You migh release it at that point.  If there are problems, we can
point to them and discuss what to do.  (I'm keen to see it
running. :-)

Earlier you said:
> Wouldn't it be easier to handle all this [selectand twiddling] when
> I call Stage.i().setDifference(someKey)? I feel a bit lost how this
> belongs in the TalkTrack. ...

Probably the link track should swallow that bit of complexity.  (Maybe
it should swallow the whole selectand business, period... not sure.)
Let's wait though, and see how ugly it looks.

M


conseo said:
> 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