On 1/15/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: > 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? as i said: only to the extend that Updates tend to have streams of data that queries don't need (as far as i can imagine)
I get it now. I was confusing UpdateHandler with RequestHandler. When looking at how to make an 'Update Plugin' I was looking at UpdateHandler.
: SolrRequest would be the current SolrQueryRequest augmented with the : HTTP method type and a way to get the raw post stream. the raw POST stream may not be where the data is though -- consider the file upload case, or the reading from a local file case, or the reading form a list of remote URLs specified in params. : 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. i disagree ... it should be possible to create "micro-plugins" (I think i called them "UpdateSource" instances in my orriginal suggestion) that know about getting streams in various ways, but don't care what format of data is found on those streams -- that would be left for the (Update)RequestHandler (which wouldn't need to know where the data came from)
I'm convinced.
: While we are at it... is there any reason (for or against) exposing : other parts of the HttpServletRequest to SolrRequestHandlers? the biggest one is Unit testing -- giving plugins very simple APIs that don't require a lot of knowledge about external APIs make it much easier to test them. it also helps make it possible for use to "future proof" plugins. other messages in this thread have discussed the possibility of changing the URL structure, supporting more restful URLs and things like that ... if we currently exposed lots of info from the HttpServletRequest in the SolrQueryRequest, then making changes like that in a backwards compatible way would be nearly impossible. As it stands, we can write a new Servlet that deals with input *completely* differently from the current URL structure, and be 99% certain that existing plugins will continue to work. : 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... all of that could concievably be done by changing the servlet to add that info into the SolrParams.
damn, you win again!
