the one thing that still seems missing is those "micro-plugins" i was
[SNIP]
interface SolrRequestParser {
SolrRequest process( HttpServletRequest req );
}
I left out "micro-plugins" because i don't quite have a good answer
yet :) This may a place where a custom dispatcher servlet/filter
defined in web.xml is the most appropriate solution.
I like the SolrRequestParser suggestion.
Consider:
qt='RequestHandler'
wt='ResponseWriter'
rp='RequestParser ' (rb='SolrBuilder'?)
To avoid possible POST read-ahead stream mungling: qt,wt, and rp
should be defined by the URL, not parameters. (We can add special
logic to allow /query?qt=xxx)
For qt, I like J.J. Larrea's suggestion on SOLR-104 to let people
define arbitrary path mapping for qt.
We could append 'wt', 'rb', and arbitrary arbitrary text to the
registered path, something like
/registered/path/wt:json/rb:standard/more/stuff/in/the/path?params...
(any other syntax ideas?)
The 'standard' RequestParser would:
GET:
fill up SolrParams directly with req.getParameterMap()
if there is a 'post' parameter (post=XXX)
return a stream with XXX as its content
else
empty iterator.
Perhaps add a standard way to reference a remote URI stream.
POST:
if( multipart ) {
read all form fields into parameter map.
return an iterator over the collection of files
}
else {
no parameters? parse parameters from the URL? /name:value/
return the body stream
}
DEL:
throw unsupported exception?
Maybe each RequestHandler could have a default RequestParser. If we
limited the 'arbitrary path' to one level, this could be used to
generate more RESTful URLs. Consider:
/myadder/1111/2222/3333/
/myadder maps to MyCustomHandler and that gives you
MyCustomRequestBuilder that maps /1111/2222/3333 to SolrParams
:
: Thoughts?
one last thought: while the interfaces you outlined would make a lot
of sense if we were starting from scratch, there are probably several
cases where not having those exact names/APIs doesn't really hurt, and
would allow backwards compatibility with more of the current code (and
current SolrRequestHandler plugin people have written) ... just something
we should keep in mind: we don't want to go hog wild renaming a lot of
stuff and alienating our existing "plugin" user base. (nor do we want to
make a bunch of unneccessary config file format changes)
I totally understand and agree.
Perhaps the best approach is to offer a SolrRequestProcessor framework
that can sit next to the existing SolrRequestHandler without affecting
it much (if at all). For what i have suggested, i *think* it could
all be done with simple additions to solrschema.xml that would still
work on an unedited 1.1.0 solrconfig.xml
If we use a servletFilter for the dispatcher, this can sit next to the
current /query?xxx servlet without problem. When the
SolrRequestProcessor framework is rock solid, we would @Deprecate
SolrRequestHandler and change the default solrconfig.xml to map /query
to the new framework.
The stuff I *DO* think should get refactored/deprecated ASAP is to
extract the constants from the functionality in SolrParams. While we
are at it, it may be good to restructure the code to something like:
http://issues.apache.org/jira/browse/SOLR-20#action_12464648
ryan
