One thought is that there isn't a "standard" set of components in the
request handler pipeline, but that they are spelled out entirely
explicitly in the request handler mapping. At that point we can
simply put in everything and the kitchen sink into the _example_
solrconfig.xml and let users prune back as desired from there.
Erik
On Oct 1, 2008, at 4:28 PM, Grant Ingersoll wrote:
SOLR-680 proposes to add StatsComponent to the set of "standard"
search components. Initially, the SpellCheckComponent did this as
well. At the time, I thought we shouldn't add them to the standard
set, but clearly others think differently.
So, I think we should have a discussion of the merits of doing so,
and try to come to some type of understanding of when something
should be "standard" and when it should be optional. I suspect, the
answer is Erik's "It depends", but let's discuss.
On the plus side, people get the new functionality without having to
configure anything. On the negative, it adds one or more if clauses
(to see if the component is on) per query per "added" component.
Not necessarily a big deal, but it is a few extra instructions that
weren't being executed before...
It also, theoretically, could cause a name clash with an existing
component that someone developed on their own. For instance, if I
had my own "spellcheck" Component, and then all of a sudden Solr put
in a new one by default, what would that mean? Would it be obvious
to me which one is being used? Is that back-compatible?
My inclination is to err on not including them by default, yet I do
think there are things that are highly valuable by default, and part
of our job as developers is to provide a good out of the box
experience. And, to me, part of that is having to do as little
configuration as possible.
Thoughts?
-Grant
