:
: 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?
(working with the assumption that most cases can be defined by a
single request parser)
I am/was suggesting that a dispatch servlet/fliter has a single
request parser. The default request parser will choose the handler
based on names defined in solrconfig.xml. If someone needs a custom
RequestParser, it would be linked to a new servlet/filter (possibly)
mapped to a distinct prefix.
If it is not possible to handle most standard stream cases with a
single request parser, i will go back to the /path:parser format.
I suggest it is configured in web.xml because that is a configurable
place that is not solrconfg.xml. I don't think it is or should be a
highly configurable component.
:
: 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.
Yes, implementing a RequestParser is more like writing a custom
Servlet then adding a Tokenizer.
