(the three of us are online way to much ... for crying out loud it's a
saturday night folks!)
: In my opinion, I don't think we need to worry about it for the
: *default* handler. That is not a very difficult constraint and, there
: is no one out there expecting to be able to post parameters in the URL
: and the body. I'm not sure it is worth complicating anything if this
: is the only thing we are trying to avoid.
you'd be suprised the number of people i've run into who expect thta to
work.
: I think the *default* should handle all the cases mentioned without
: the client worrying about different URLs for the various methods.
:
: The next question is which (if any) of the explicit parsers you think
: are worth including in web.xml?
holy crap, i think i have a solution that will make all of us really
happy...
remember that idea we all really detested of a public plugin interface,
configured in the solrconfig.xml that looked like this...
public interface RequestParser(
SolrRequest parse(HttpServletRequest req);
}
...what if we bring that idea back, and let people configure it in the
solrconfig.xml, using path like names...
<requestParser name="/raw" class="solr.RawPostRequestParser" />
<requestParser name="/multi" class="solr.MultiPartRequestParser" />
<requestParser name="/nostream" class="solr.SimpleRequestParser" />
<requestParser name="/guess" class="solr.UseContentTypeRequestParser" />
...but don't make it a *public* interface ... make it package protected,
or maybe even a private static interface of the Dispatch Filter .. either
way, don't instantiate instances of it using the plugin-lib ClassLoader,
make sure it comes from the WAR to only uses the ones provided out of hte
box.
then make the dispatcher check each URL first by seeeing if it starts with
the name of any registered requestParser ... if it doesn't then use the
default "UseContentTypeRequestParser" .. *then* it does what the rest of
ryans current Dispatcher does, taking the rest of hte path to pick a
request handler.
the bueaty of this approach, is that if no <requestParser/> tags appear in
the solrconfig.xml, then the URLs look exactly like you guys want, and the
request parsing / stream building semantics are exactly the same as they
are today ... if/when we (or maybe just "i") write those other
RequestParsers people can choose to turn them on (and change their URLs)
if they want, but if they don't they can keep having the really simple
URLs ... OR they could register something like this...
<requestParser name="" class="solr.RawPostRequestParser" />
...and have really simple URLs, but be garunteed that they allways got
their streams from raw POST bodies.
This would also solve Ryans concern about allowing people to turn off
fetching streams from remote URLs (or from local files, a small concern i
had but hadn't mentioend yet since we had bigger fish to fry)
Thoughts?
-Hoss
