Yonik, i could not get your last patch to apply cleanly to trunk. This is my best attempt to resolve the conflicts and fix a few things.
1. remove the call to getResponseBuilder() in SearchComponent
2. the timing info was commented out of debugging
The dismax changes look great - i like the new query parser stuff!
> - removed variable RequestBuilder class logic since it seems unnecessary...
> if two non-standard components want to communicate something, they can
> use the Context or the Response. (any reason I'm missing why it should stay?)
If at all possible, I think we should do our best to avoid depending on Map<String> for an interface.
> We need to think through all the members of ResponseBuilder carefully and decide what component sets/reads them in what phase (and if that makes the most sense).
> Should ResponseBuilder have methods instead of members? If so, that would allow a component to perhaps even replace the ResponseBuilder and delegate to the original.
yes, that makes sense. How would a component replace the ResponseBuilder? If it could do that, there is obviously no need for the variable RequestBuilder class logic
> How will a users custom component get configuration? Should components be a full plugins with an init() for configuration?
As is, they are defined in a "components" section for SearchHandler (from the example solrconfig.xml):
<requestHandler name="/search" class="solr.SearchHandler">
Perhaps the components should be passed the init params?
Unless there is a compelling reason, I don't think components need to be shared across request handlers thus justifying a top level component registry.