Cool. I think i need more examples... concrete is good :-)
I don't quite grok your format below... is it one line or two?
/path/defined/in/solrconfig:parser?params
/${handler}:${parser}
Is that simply
/${handler}:${parser}?params
yes. the ${} is just to show what is extracted from the request URI,
not a specific example
Imagine you have a CsvUpdateHander defined in solrconfig.xml with a
"name"="my/update/csv".
The standard RequestParser could extract the parameters and
Iterable<ContentStream> for each of the following requests:
POST: /my/update/csv/?separator=,&fields=foo,bar,baz
(body) "10,20,30"
POST:/my/update/csv/
multipart post with 5 files and 6 form fields defining
(unlike the previous example this the handle would get 5 input streams
rather then 1)
GET: /my/update/csv/?post.remoteURL=http://..&separator=,&fields=foo,bar,baz&;...
fill the stream with the content from a remote URL
GET: /my/update/csv/?post.body=bodycontent,&fields=foo,bar,baz&...
use 'bodycontent' as the input stream. (note, this does not make much
sense for csv, but is a useful example)
POST: /my/update/csv:remoteurls/?separator=,&fields=foo,bar,baz
(body) http://url1,http://url2,http:/url3...
In this case we would use a custom RequestParser ("remoteurls") that
would read the post body and convert it to a stream of content urls.
- - - - - - -
The URL path (everything before the ':') would be entirely defined and
configured by solrconfig.xml A filter would see if the request path
matches a registered handler - if not it will pass it up the filter
chain. This would allow custom filters and servlets to co-exist in
the top level URL path. Consider:
solrconfig.xml
<handler name="delete" class="DeleteHandler" />
web.xml:
<servlet-mapping>
<servlet-name>MyRestfulDelete</servlet-name>
<url-pattern>/mydelete/*</url-pattern>
</servlet-mapping>
POST: /delete?id=AAA would be sent to DeleteHandler
POST: /mydelete/AAA/ would be sent to MyRestfulDelete
Alternativly, you could have:
solrconfig.xml
<handler name="standard/delete" class="DeleteHandler" />
web.xml:
<servlet-mapping>
<servlet-name>MyRestfulDelete</servlet-name>
<url-pattern>/delete/*</url-pattern>
</servlet-mapping>
POST: /standard/delete?id=AAA would be sent to DeleteHandler
POST: /delete/AAA/ would be sent to MyRestfulDelete
I am suggesting we do not try have the default request servlet/filter
support extracting parameters from the URL. I think this is a
reasonable tradeoff to be able to have the request path easily user
configurable using the *existing* plugin configuration.
- - - - - - - -
In a previous email, you mentioned changing the URL structure. With
this proposal, we would continue to support:
/select?wt=XXX
for the Csv example, you would also be able to call:
GET: /select?qt=/my/update/csv/&post.remoteURL=http://..&sepa...
ryan
