On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: I'm on board as long as the URL structure is:
: ${path/from/solr/config}?stream.type=raw
actually the URL i was suggesting was...
${parser/path/from/solr/config}${handler/path/from/solr/config}?param=val
...i was trying to avoid keeping the parser name out of the query string,
so we don't have to do any hack parsing of
HttpServletRequest.getQueryString() to get it.
We need code to do that anyway since getParameterMap() doesn't support
getting params from the URL if it's a POST (I believe I tried this in
the past and it didn't work).
Aesthetically, having an optional parser in the queryString seems
nicer than in the path.
basically if you have this...
<requestParser name="/raw" class="solr.RawPostRequestParser" />
<requestParser name="/multi" class="solr.MultiPartRequestParser" />
<requestParser name="/nostream" class="solr.SimpleRequestParser" />
Pluggable request parsers seems needlessly complex, and it gets harder
to explain it all to someone new.
Can't we start simple and defer anything like that until there is a real need?
if they really had a reason to want to force one type of parsing, they
could register it with a differnet prefix.
That is a point. I'm not sure of the usecases though... it's not safe
to let untrusted people update solr at all, so I don't understand
prohibiting certain types of streams.
* default URLs stay clean
* no need for an extra "stream.type" param
* urls only get ugly if people want them to get ugly because they don't
want to make their clients set the mime type correctly.
The first and last points are also true for a stream.type type of thing.
After all, we will need other parameters for specifying local files,
right? Or is opening local files up to the RequestHandler again?
Anyway, I'm not too unhappy either way, as long as I can leave out any
explicit "parser" and just get the right thing to happen.
-Yonik
