: The RequestParser is not be part of the core API - It would be a
: helper function for Servlets and Filters that call the core API. It
: could be configured in web.xml rather then solrconfig.xml. A
: RequestDispatcher (Servlet or Filter) would be configured with a
: single RequestParser.
:
: The RequestParser would be in charge of taking HttpRequest and determining:
: 1) The RequestHandler
: 2) The SolrRequest (Params & Streams)
This sounds fine to me ... i was going to suggest that having a public API
for RequestParser that people could extend and register intsnces of in the
solrconfig would be better then no public API at all -- but if we do that
we've let the genie out of the bottle, better to be more restrictive about
the internal API, and if/when new usecase come up we can revisit the
decision then.
If the RequestParser is going to pick the RequestHandler, we might as
stick with the current model where the RequestHandler is determined by the
"qt" SolrParam (it just wouldn't neccessarily come from the "qt" param of
the URL, since the RequestParser can decide where everything comes form
it could be from a URL param or it could be from the path) to keep the API
simple right?
interface RequestParser {
public SolrRequest makeSolrRequest(HttpServletRequest req);
}
I'm curious though why you think RequestParsers should be managed in the
web.xml ... do you mean they would each be a Servlet Filter? ... if we
assume there's going to be a fixed list and they aren't easily extended,
then why not just:
- have a HashMap of them in a single ServletFilter dispatcher,
- lookup the one to use pased on the appropriate part of the path
- let that RequestParser make the SolrRequest
- continue with common code for all requests regardless of format:
- get RequestHandler from the core by name
- execute RequestHandler
- get output writer by name
- write out response
: It would not be the most 'pluggable' of plugins, but I am still having
: trouble imagining anything beyond a single default RequestParser.
what!? .. really????? ... you don't think the ones i mentioned before are
things we should support out of the box?
- no stream parser (needed for simple GETs)
- single stream from raw post body (needed for current updates
- multiple streams from multipart mime in post body (needed for SOLR-85)
- multiple streams from files specified in params (needed for SOLR-66)
- multiple streams from remote URL specified in params
: Assuming anything doing *really* complex ways of extracting
: ContentStreams will do it in the Handler not the request parser. For
: reference see my argument for a seperate DocumentParser interface in:
:
http://www.nabble.com/Re%3A-Update-Plugins-%28was-Re%3A-Handling-disparate-data-sources-in-Solr%29-p8386161.html
aggreed ... but that can easily be added later.
: In my view, the default one could be mapped to "/*" and a custom one
: could be mapped to "/mycustomparser/*"
:
: This would drop the ':' from my proposed URL and change the scheme to look
like:
: /parser/path/the/parser/knows/how/to/extract/?params
i was totally okay with the ":" syntax (although we should double check if
":" is actaully a legal unescaped URL character) .. but i'm confused by
this new suggestions ... is "parser" the name of the parser in that
example and "path/the/parser/knows/how/to/extract" data that the parser
may use to build to SolrRequest with? (ie: perhaps the RequestHandler)
would parser names be required to not have slashes in them in that case?
: > Imagine if 3 years ago, when Yonik and I were first hammering out the API
: > for SolrRequestHandlers, we had picked this...
: >
: > public interface SolrRequestHandlers extends SolrInfoMBean {
: > public void init(NamedList args);
: > public void handleRequest(HttpServletRequest req, SolrQueryResponse
rsp);
: > }
:
: Thank goodness you didn't! I'm confident you won't let me (or anyone)
: talk you into something like that! You guys made a lot of good
the point i was trying to make is that if we make a RequestParser
interface with a "parseRequest(HttpServletRequest req)" method, it amouts
to just as much badness -- the key is we can make that interface as long
as all the implimentations are in the SOlr code base where we can keep an
eye on them, and people have to go way, WAY, *WAY* into solr to start
shanging them.
-Hoss
