For the record, i know next to nothing about highlighting in Lucene.  i
can't remember if i read that chapter in LIA or not :)

: curious if the standard handler and configuration should evolve to
: handle the common need for search term highlighting, and if so how

+1

: would that ideally look in the configuration and search request?

one of the things i've been doing in my custom plugins (one of which is
really generic and i'm hoping to get permission to commit it back to solr
real soon now) is to make every possible query param have a corrisponding
identically named init param (in the solr config) which it uses as the
default.  That way you can have...
    <str name="highlightFields">title description</str>
...in your solrconfig.xml, and clients that want differnet behavior can
override it with...
   highlightFields=title+description+body
...in the URL.

: I am game for developing the highlighting piece in some way in the
: next few days, and would gladly contribute that feature back provided
: it was done in a way that fits with Solr's architecture.

from a usage standpoint, i think adding both a URL param and init param
to StandardRequestHandler that takes in a space seperated list of
fieldNames to highlight makes a lot of sense ... the question is what do
we do with it?

Modifing XMLWriter and SolrQueryResponse to have "defaultHighlightFields"
in the same way they currently have "defaultReturnFields" seems like it
makes the most sense, (especially since that way other plugins can use it
as well).  Then the XMLWriter can include a new <hi>word</hi> in it's
output anytime it wants to highlight something.

(NOTE: Adding XML markup for highlighting probably means the default
"Protocol Version" should be rev'ed to 2.2, and highlighting should be
flat out disabled if the version is less then that  so older clients
aren't suddenly suprised to find xml markup in their strings if the server
configuration cahnges)


-Hoss

Reply via email to