I very much support a plugin architecture for ResponseHandlers. One aspect could be a "Responselet" which adds something to the response, as detailed in Ryan's example below. Quite valuable in itself.
But another aspect could be a "Querylet" which adds something to the query before execution. For example, if we were to bust up the venerable old (!) DisMaxRequestHandler into constituent parts: a) Escaped dismax query spanning multiple field^boost combinations, with configurable minShouldMatch b) Escaped adjacency (phrase) query contributing to document boost c) Supplemental term-based boosting queries d) Supplemental function-based boosting queries e) Filter queries (also in StandardRH, but in both cases not part of main query construction) I don't see any reason (c) and (d) and perhaps (b) can't be used for Standard-style queries. Unless I'm mistaken, that could be accomplished with some refactoring and inheritance (getMainQuery(...), getBoostingQueries(...)), but a plugin architecture would be rather more flexible. Perhaps response and query plugins should be treated as independent cases, with the latter deferred to a different discussion, but it would be awfully nice if DisMaxRH differed from StandardRH only as a construction in solrconfig.xml! <BlueSky> Quickly thinking aloud... If a plugin declared whether it needed to be run pre-query or post-query (or non-query), and for post-query whether it needs DocListAndSet or just DocList, perhaps the structure could be something like: For each pre- or non-query plugin plugin(SolrParams, Response, MainQuery, FilterQuery) -> (SolrParams, Response, MainQuery, FilterQuery) Execute Query For each post-query plugin plugin(SolrParams, Response, DocList/Set) -> (SolrParams, Response, DocList/Set, ...) Which suggests to me that instead of formal params, the plugins could communicate through a self-extensible Map-derived namespace, with predefined names for rendezvous but allowing two or more plugins to pass information to each other with locally define parameter names. The namespace could be lazy with generators, e.g. the first request for "DocSet" would execute the query and add DocList and DocSet entries to it. Hmm, perhaps it ALL could be implemented as lazy generators... </BlueSky> Anyway, it's a thought which would obviously need to be worked out much more thoroughly. - J.J. At 11:04 AM -0700 6/10/07, Ryan McKinley wrote: > // choose one query method > docs = Query( req, debug ) > - standard > - dismax > - mlt (as input) > - ... > > // zero or more... > info[] = Info( req, docs, debug ) > + facet > + mlt (on each result) > + ... ...