Talk track filtering

[conseo]

Hey Mike,

> 
> Let's document a filtering convention for the stage API.  This affects
> both our code, and also the "actorName" problem we chatted about:
> http://zelea.com/var/cache/irc/votorola/12-10/08
> 
> Here's what I propose.  This assumes a poll is staged: [1]
> 
> 
>    defaultActorName [2]  actorName [3]  filter
>    -------------------------------------------
>    free        null      null           forest
> 
>                null      end            forest
>                          candidate
> 
>                null      non end        branch
>                          candidate

This has to be implemented properly next, because it needs apropriate mapping 
to counts and the trees. We have discussed some approaches already.

>    -------------------------------------------
>    pinned      set       default        group

This is how it works atm.

> 
>                set       non-default    pair

This does not work yet.

> 
> 
> You'll probably be filtering on other properties too, but currently
> only the actor is a mutual dependency, and only when a poll is staged
> *and* the track is pinned.  So it's only the bottom half that we need
> to document in the API.  But I discuss all four filters below.
> 
> free
> ----
> Here the vote track is animated and the user may explore votespace.
> Talk lighting may be used to show the way, much as in geospace with
> the geotrack [5].  Filtering is consistent with this.
> 
> (forest) Talk track shows diff messages for entire poll, i.e. entire
> votespace forest.
> 
> (branch) Talk track shows messages for upstream votespace branch
> (deep) as rooted in actor's candidate, i.e. including the candidate.
> 
> pinned
> ------
> Here the vote track is pinned to the default actor and immobile [4].
> This happens in draft pages and the difference bridge, for instance,
> where it allows for pair selection *instead of* exploring votespace.
> Again, filtering is consistent with this.
> 
> (group) Talk track shows diff messages for default actor (pin) and
> immediate cast relations, viz. with diffs between the pin and an
> immediate voter, co-voter, base co-candidate, or candidate. [6]
> 
> (pair) Talk track shows all diff messages between the pin and actor.
> 
> There's probably no need to actually code any filtering for your first
> deployment.  We only need to agree on the plan.  What do you think?

Following our structuring of the discourse in the tree form, your proposed 
filtering shows all communication regarding the current context. Pinning 
limits it to group level, while for browsing vote space we want to show all 
relevant discussion on that level. So I agree. 

conseo