At 11:48 PM -0800 1/16/07, Chris Hostetter wrote: >yeah ... once we have a RequestHandler doing that work, and populating a >SolrQueryResponse with it's result info, it >would probably be pretty trivial to make an extremely bare-bones >LegacyUpdateOutputWRiter that only expected that simple mount of response >data and wrote it out in the current update response format .. so the >current SolrUpdateServlet could be completley replaced with a simple url >mapping... > > /update --> /select?qt=xmlupdate&wt=legacyxmlupdate
Yah! But in my vision it would be /update -> qt=update because pathInfo is "update". There's no need to remap anything in the URL, the existing SolrServlet is ready for dispatch once it: - Prepares request params into SolrParams - Sets params("qt") to pathInfo - Somehow (perhaps with StreamIterator) prepares streams for RequestParser use I'm still trying to conceptually maintain a separation of concerns between handling the details of HTTP (servlet-layer) and handling different payload encodings (a different layer, one I believe can be invoked after config is read). The following is "vision" more than "proposal" or "suggestion"... <requestHandler name="update" class="lets.write.this.UpdateRequestHandler"> <lst name="invariants"> <str name="wt">legacyxml</str> </lst> <lst name="defaults"> <!-- rp matches queryRequestParser --> <str name="rp">xml</str> </lst> </request> <!-- only if standard responseWriter is not up to the task --> <queryResponseWriter name="legacyxml" class="do.we.really.need.LegacyUpdateOutputWRiter"/> <queryRequestParser name="xml" class="solr.XMLStreamRequestParser"/> <queryRequestParser name="json" class="solr.JSONStreamRequestParser"/> So when incoming URL comes in: /update?rp=json the pipeline which is established is: SolrServlet -> solr.JSONStreamRequestParser | |- request data carrier e.g. SolrQueryRequest | lets.write.this.UpdateRequestHandler | |- response data carrier e.g. SolrQueryResponse | do.we.really.need.LegacyUpdateOutputWRiter I expect this is all fairly straightforward, except for one sticky question: Is there a "universal" format which can efficiently (e.g. lazily, for stream input) convey all kinds of different request body encodings, such that the RequestHandler has no idea how it was dispatched? Something to think about... - J.J.