On 1/18/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 1/18/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: > Yes, this proposal would fix the URL structure to be > /path/defined/in/solrconfig:parser?params > /${handler}:${parser} > > I *think* this cleanly handles most cases cleanly and simply. The > only exception is where you want to extract variables from the URL > path.But that's not a hypothetical case, extracting variables from the URL path is something I need now (to add metadata about the data in the raw post body, like the CSV separator). POST to http://localhost:8983/solr/csv?separator=,&fields=foo,bar,baz with a body of "10,20,30"
Sorry, by "in the URL" I mean "in the URL path." The RequestParser can extract whatever it likes from getQueryString() The url you list above could absolutely be handled with the proposed format. The thing that could not be handled is: http://localhost:8983/solr/csv/foo/bar/baz/ with body "10,20,30"
> There are pleanty of ways to rewrite RESTfull urls into a > path+params structure. If someone absolutly needs RESTfull urls, it > can easily be implemented with a new Filter/Servlet that picks the > 'handler' and directly creates a SolrRequest from the URL path. While being able to customize something is good, having really good defaults is better IMO :-) We should also be focused on exactly what we want our standard update URLs to look like in parallel with the design of how to support them.
again, i totally agree. My point is that I don't think we need to make the dispatch filter handle *all* possible ways someone may want to structure their request. It should offer the best defaults possible. If that is not sufficient, someone can extend it.
