SolrRequestHandler => SolrUpdateHandler
SolrQueryRequest => SolrUpdateRequest
SolrQueryResponse => SolrUpdateResponse (possibly the same class)
QueryResponseWriter => UpdateResponseWriter (possible the same class)
Is there any reason the plugin system needs a different RequestObject
for Query vs Update?
I think the most flexible system would have the plugin manager take
any HttpServletRequest, convert it to a 'SolrRequest' and pass it to a
RequestHandler.
SolrRequest would be the current SolrQueryRequest augmented with the
HTTP method type and a way to get the raw post stream.
Likewise I don't see anything in QueryResponseWriter that should tie
it to 'Query.' Could it just be ResponseWriter?
This way the plugin system would not need to care if its a
query/update/ or some other command someone wants to add.
1) where does the "stream" of update data come from? is it in the raw
POST body? is it in a POSTed multi-part MIME part? is it a remote
resource refrenced by URL?
I'm not sure the nitty gritty, but it should be as close to
HttpServletRequest as possible. If possible, I think handlers should
choose how to handle the stream.
It it is a remote resource, I think its the handlers job to open the stream.
2) how should the raw binary stream of update data be parsed? is it
XML? (in the current update format) is it a CSV file? is it a PDF?
...#2 can be what the SolrUpdateHandler interface is all about -- when
hitting the update url you specify a "ut" (update type) that determines
that logic ... but it should be independed of #1
maybe the full list of stream sources for #1 is finite and the code for
all of them can live in the UpdateServlet ... but it still needs to be an
option configured as a param, and it seems like it might as well be a
plugin so it's easy for people to write new ones in the future.
-Hoss
While we are at it... is there any reason (for or against) exposing
other parts of the HttpServletRequest to SolrRequestHandlers?
While it is not the focus of solr, someone (including me!) may want to
implement some more complex authentication scheme - Perhaps setting a
field on each document saying who added it and from what IP.
stuff to consider: cookies, headers, remoteUser, remoteHost...
ryan
