First Ryan, thank you for your patience on this *very* long hash session. Most wouldn't last that long unless it were a flame war ;-) And thanks to Hoss, who seems to have the highest read+response bandwidth of anyone I've ever seen (I'll admit I've only been selectively reading this thread, with good intentions of coming back to it).
On 1/19/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
It would not be the most 'pluggable' of plugins, but I am still having trouble imagining anything beyond a single default RequestParser. Assuming anything doing *really* complex ways of extracting ContentStreams will do it in the Handler not the request parser.
Agreed... a custom handler opening various streams not covered by the default will most easily be handled by the handler opening the streams themselves.
This would give people a relativly easy way to implement 'restful' URLs if they need to. (but they would have to edit web.xml)
A handler could alternately get the rest of the path (absent params), right?
Correct, SolrCore shoudl not care what the request path is. That is why I want to deprecate the execute( ) function that assumes the handler is defined by 'qt' Unit tests should be handled by execute( handler, req, res )
How does the unit test get the handler?
If I had my druthers, It would be: res = handler.execute( req ) but that is too big of leap for now :)
Yep... esp since the response writers now need the request for parameters, for the searcher (streaming docs, etc).
You guys made a lot of good choices and solr is an amazing platform for it.
I just wish I had known Lucene when I *started* Sol(a)r ;-)
I am proposing we have a single interface to do this: SolrRequest r = RequestParser.parse( HttpServletRequest )
That's currently what new SolrServletRequest(HttpServletRequest) does. We just need to figure out how to get InputStreams, Readers, etc.
I agree. This is why i suggest the RequestParsers is not a core part of the API, just a helper class for Servlets and Filters.
Sounds good to as a practical starting point to me. If we need more in the future, we can add it then. USECASE: The XML update plugin using the woodstox XML parser: Woodstox docs say to give the parser an InputStream (with char encoding, if available) for best performance. This is also preferable since if the char isn't specified, the parser can try to snoop it from the stream. So, the hander needs to be able to get an InputStream, and HTTP headers. Other plugins (CSV) will ask for a Reader and expect the details to be ironed out for it. Method1: come up with ways to expose all this info through an interface... a "headers" object could be added to the SolrRequest context (see getContext()) Method2: consider it a more special case, have an XML update servlet that puts that info into the SolrRequest (perhaps via the context again) -Yonik
