:
: One interesting/difficult part would be the standardization of the
: communication between components.
Communication can be coordinated with things like
SolrQueryRequest.getContext() ... it will have to be fairly loose
communication governed by convetion, but i don't see anyway to avoid that
in a 'generalized' appraoch like this.
dooh. I just posted "I don't think this would be much fun"
I think you are right, with a general approach, there is no way to avoid
Map<String,Object> as the base communication. BUT I hope we can build
up a stronger typed response builder that handles intermediate states
for the most general cases. That is, I would rather work with:
builder.setNeedDocSet( true );
...
builder.getDocList();
then:
getContext().put( "DocList", docList );
or even:
getContext().put( ResponseHelper.DOC_LIST, docList );
A good 'ResponceBuilder' design would make passing around common things
easier. This should include some sort of dependency list(tree?) that
gets filled up in the "prepare" loop and taken care of in the "process"
loop.
: This is all still so early, and at a high enough level, I'm not saying
: I favor this approach over any other... It's just the first that
: occurred to me.
I think the best appraoch to helping us find what the "contact points"
should be between various pieces of functionality would be to try and
refactor dismax, standard, and mlt to reuse as much code as possible and
see what common API "hook points" come out of it.
Yes!
