: > 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. : : But that doesn't seem possible unless we make user plugins : second-class citizens by scoping them differently. In the event there : is a collision in the future, the user could rename one of the : plugins.
when it comes to URLs, our plugins currently are second class citizens -- plugin names appear in the "qt" or "wt" params -- users can pick any names they want and they are totally legal, they don't have to worry about any possibility that a name they pick will collide with a path we have mapped to a servlet. Users shouldn't have the change the names of requestHandlers juse because SOlr adds a new feature with the same name -- changing a requestHandler name could be a heavy burden for a Solr user to make depending on how many clients *they* have using that requestHandler with that name. i wouldn't make a big deal out of this if it was unavoidable -- but it is such an easy thing to deal with just by scoping the URLs .. put something, ANYTHING, in front of these urls, that isn't "select" or "update" and then put the requestHandler name and we've now protected ourself and our users. consider the case where a user today has this in his solrconfig... <requestHandler name="select" class="solr.StandardRequestHandler"> ..with the URL structure you guys are talking about, with the DispatchFilter matching on /* and interpreting the first part of hte path as a posisble requestHandler name, that user can't upgrade Solr because he's relying on the old "/select?qt=select" style URLs to work ... he has to change the name of his requestHandler and all of his clients, then upgrade, then change all of his clients againt to take advantage of the new URL structure (and the new features it provides for updates) -Hoss
