SolrRequestHandler implementations

[John Wang <jo...@gmail.com>]

Solr developers:

There are different SolrRequestHandler implementations in Solr, e.g.
DisMaxRequestHandler, StandardRequestHandler and they overlap in
functionality.

And we are thinking of writing our own SolrRequestHandler implementation,
which means to also support standard functionality, we'd have to copy over
most of the code from existing implementations. This sort of code
replication is usually not good.

Are there plans to rethink the plugin architecture, e.g. to break into
phases or modules where other components/plugins can extend? Or what are
some other suggestions you guys may have?

Thanks

-John

Re: SolrRequestHandler implementations

[Ryan McKinley <ry...@gmail.com>]

> 
> Are there plans to rethink the plugin architecture, e.g. to break into
> phases or modules where other components/plugins can extend? Or what are
> some other suggestions you guys may have?
> 

Check org.apache.solr.util.SolrPluginUtils -- ideally most functionality 
shared across multiple RequestHandlers can live in shared utility 
classes like this...

Re: SolrRequestHandler implementations

[Yonik Seeley <yo...@apache.org>]

On 5/29/07, John Wang <jo...@gmail.com> wrote:
> Are there plans to rethink the plugin architecture, e.g. to break into
> phases or modules where other components/plugins can extend? Or what are
> some other suggestions you guys may have?

Yes, I've considered the need for it. It would allow someone to add
information to a response w/o having to copy an existing request
handler.

The main difficulty lies in interdependencies.  Some phases will just
have to have knowledge about the other phases.  For example, if
facet=true, then it's most efficient for the query phase to call
getDocSetAndList rather than just getDocList.

The other minor issue is where to put shared data (like the base
DocSet to use for faceting) ... probably the request context object.

The biggest question is if it's worth it, and if it would work for
enough of the customizations people would want to make.

-Yonik