On Apr 7, 2006, at 2:33 PM, Yonik Seeley wrote:
Is it possible to approach this (using a config microkernel) in an
incremental and backward compatible way?
I can't say entirely for sure, but I think so. We could make a
MicrokernalRequestHandler and within it would be the HiveMind
container mojo leaving the standard request handler alone while we
iron out the kinks.
I agree that we would gain a lot (in the long run) by using something
like Spring or Hivemind.
Spring, at least from my well-read but virgin perspective, is a big
bite to take. It's J2EE redone, and while it is easy to use within
our context we'd only be using a fraction of what "Spring" offers
overall. HiveMind is a no-frills way to do the same thing.
ps: I worry slightly about going with Hivemind over Spring (which
seems to have won the popularity contest in a big way).
Tapestry users expressed the same concern, but both play fine
together. There are gateways to Spring from HiveMind, allowing a
system to use Spring for another subsystem, and wire beans into
Solr's HiveMind configuration into its Spring container. So we
definitely would not be closing the doors to someone using Spring,
but Solr's configuration would be in HiveMind. And for all I know,
there may be a one-line way to wire up HiveMind to get all its
configuration via Spring as well. I'm copying in Howard Lewis Ship
so he can see that we're discussing, without much actual experience
in this speaking for myself, ways to wire in flexible configuration
into Solr and what his thoughts on it might be.
Erik
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
