: > then all is fine and dandy ... but what happens if someone tries to : > configure a plugin with the name "admin" ... now all of the existing admin
: that is exactly what you would expect to happen if you map a handler : to /admin. The person configuring solrconfig.xml is saying "Hey, use : this instead of the default /admin. I want mine to make sure you are : logged in using my custom authentication method." In addition, It may : be reasonable (sometime in the future) to implement /admin as a : RequestHandler. This could be a clean way to address SOLR-58 (xml : with stylesheets, or JSON, etc...) yeah i guess that wouldn't be too horrible ... i think what i was trying to point out was that if we'd roll out these super simple urls containg just the plugin name and someone did register a plugin overriding the admin pages, we'd screw them over later when we did get arround to replacing the admin pages with a plugin if added it as a special override ServletFilter mapping : > also: what happens a year from now when we add some completely new : > Servlet/ServletFilter to Solr, and want to give it a unique URL... : > : > http://host:9999/solr/bar/ : obviously, I think the default solr settings should be prudent about : selecting URLs. The standard configuration should probably map most : things to /select/xxx or /update/xxx. the thing about Solr, is there really aren't a lot of "defaults" in the sense you mean ... there is just an example -- people might copy the example, but if they don't have something in their solrconfig, most things just aren't there.... : > ...we could put it earlier in the processing chain before the existing : > ServletFilter, but then we break any users that have registered a plugin : > with the name "bar". : : Even if we move this to have a prefix path, we run into the exact same : issue when sometime down the line solr has a default handler mapped to : 'bar' the point i was trying to make is that the "namespaces" that Solr uses should be unique -- the piece of the URL path that is used to pick the Servlet or filter for dispatching the request, should be uniquely distinguishable from the piece of the URL that is used to lookup a plugin. A user should be confident that they can pick anyname they possily want for their plugin, and it won't collide with any future addition we might add to Solr. if the new and improved solr URLs (minus host:port/context) are just /${plugin}/... with a dispatcher that matches on any URL and checks that path for a plugin matching that name then we have no way of ever adding any other URL for a new in the future without running the risk that whatever bsae path we pick for that new features URLs, we might screw over a user who just so happened to pick that features name when registering a plugin -- either becuase we put the new feature earlier in the FilterChain and it circumvents requests the user expects to to that plugin, or because we put that feature later in the FilterChain and that user doesn't ge to take advantage of it unless he changes the name he registered the plugin with (and changes all of his clients) i would relaly feel a lot happier with something like these that you mentioned... : /solr/dispatch/update/xml : /solr/cmd/update/xml : /solr/handle/update/xml : /solr/do/update/xml http://${host}:${port}/${context}/do/${parser}/${handler/with/optional/slashes}?${params} ....sounds great to me... just as long as we have some constant prefix in there so that later on we can use something else. we can still handle... http://${host}:${port}/${context}/select/?qt=${handler}&${params} ..with a really simple ServletFilter (that has no risk of collision, with the new URL structure one, so it can go anywhere in the FilterChain) -Hoss
