I've thought of using Spring before http://www.mail-archive.com/solr-dev@lucene.apache.org/msg00200.html
I was thinking of something like that for replacing much of solrconfig.xml for specifying the update handler implementation, query handlers, caches, etc. It makes sense to make QueryParsers a pluggable thing too... Is it possible to approach this (using a config microkernel) in an incremental and backward compatible way? I agree that we would gain a lot (in the long run) by using something like Spring or Hivemind. -Yonik ps: I worry slightly about going with Hivemind over Spring (which seems to have won the popularity contest in a big way). On 4/7/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: > Here's my opinion on this matter... a StandardRequestHandler > shouldn't even need to be subclassed to plug in different query > parsers. This is where a microkernal framework such as HiveMind > would really shine. I'm ashamed to admit that I'm not skilled in the > ways of HiveMind Jedi, despite my Tapestry immersion, but the > benefits HiveMind offer are exactly for this sort of pluggable > features capability. I see several facets to a request handler and > each of these should be tunable by simple configuration: query > parsing, (possible future) multiple index support, request and > response protocols (OpenSearch, Solr XML, XML-RPC), highlighting, > security (a big one I haven't seen discussed here), and more. So > rather than a subclassing architecture, let's go for a kernel > architecture where we can plug in features easily very modularly via > configuration rather Java code. > > Anyone here toyed with HiveMind or Spring? I'd like to eat our own > dog food and give HiveMind a try though. Ah, yet another fun idea to > put on my TODO list! Maybe I'll be lucky and someone beats me to it :) > > Erik > > On Apr 7, 2006, at 12:12 PM, Yonik Seeley wrote: > > > On 4/6/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > >> : The easiest way would be to add another parameter specifying the > >> : default query syntax. > >> : qformat=lucene // default QueryParser syntax > >> : qformat=xml // Mark's XML query syntax > >> : qformat=surround // Paul's surround query syntax > >> > >> You mean the the standard request handler? > >> > >> Why not add an XmlRequestHandler and an SurroundRequestHandler > >> that each > >> parse their "q" param using the appropraite parser? > > > > If the only thing one wants to change is the format of the Lucene > > query itself, and not the complete request (Paul's surround syntax > > might be a better example), and it's a broadly applicable query > > format, then why make a whole new handler? > > > > But, it would make sense if enough stuff was different (query args, > > way to specify return fields, return format, etc). For example, I > > imagine that enough stuff would be different for OpenSearch support > > that it would make sense to have a different handler. > > > > -Yonik
