: 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)?
I don't really see it being a very high cost ... and even if we can't imagine any other potential user written RequestParser, we already know of at least 4 use cases we want to support out of the box for getting streams: 1) raw post body (as a single stream) 2) multi-part post body (file upload, potentially several streams) 3) local file(s) specified by path (1 or more streams) 4) remote resource(s) specified by URL(s) (1 or more streams) ...we could put all that logic in a single class with that looks at a SolrParam to pick what method to use or we could extract each one into it's own class using a common interface ... either way we can hardcode the list of viable options if we want to avoid the issue of letting the client configure them .. but i still think it's worth the effort to talk about what that common interface might be. I think my idea of having both a preProcess and a process method in RequestParser so it can do things before and after the Servlet has extracted SolrParams from the URL would work in all of the cases we've thought of. -Hoss
