OK, trying to catch up on this huge thread... I think I see why it's become more complicated than I originally envisioned.
What I originally thought: 1) add a way to get a Reader or InputStream from SolrQueryRequest, and then reuse it for updates too 2) use the plugin name in the URL 3) write code that could handle multi-part post, or could grab args from the URL. 4) profit! I think the main additional complexity is the idea that RequestParser (#3) be both pluggable and able to be specified in the actual request. I hadn't considered that, and it's an interesting idea. Without pluggable RequestParser: - something like CSV loader would have to check the params for a "file" param and if so, open the local file themselves With a pluggable RequestParser: - the LocalFileRequestParser would be specified in the url (like /update/csv:local) and it will handle looking for the "file" param and opening the file. The CSV plugin can be a little simpler by just getting a Reader. - a new way of getting a stream could be developed (a new RequestParser) and most stream oriented plugins could just use it. However, I'm not yet convinced the benefits are worth the costs. If the number of RequestParsers remain small, and within the scope of being included in the core, that functionality could just be included in a single non-pluggable RequestParser. I'm not convinced is a bad idea either, but I'd like to hear about usecases for new RequestParsers (new ways of generically getting an input stream)? -Yonik
