: Thanks Bertrand, I've not used servlet filters before. : : What do people think the tradeoffs are of using a different url : "/select/html" vs a different response writer "wt=html&wt.xslt=..." ?
1) it shouldn't be /select/html ... select/xslt or something, but there's no reason to assume the output of the XSLT would be html 2) in spirit, i like hte idea of supporting both client site XSLT (with the current XMLOutputWriter and some improved handling of hte stylesheet param) and server side XSLT (wiht something like this patch) ... but i'm a little leary of "overfilling the toolbox" with features. this is nothing against this patch ... i just worry that as Solr grows and we get more OutputWriters and RequestHandlers we're going to want to have a limited number of "core plugins" that ship out of hte box, and a jar of additional plugins that people can use if they want, but don't need loaded into the JVM by people who don't care (much the way lucene has language specific analyzers in a contrib module -- having an OutputWriter that generates tab delimited results, or a ServletFilter that trims whitespace are all usefull features, but shouldn't neccessarily be in the core) with most things, putting them in a seperate JAR and having good instructions on loading them into Solr's classpath for various ServletContainers would probably be fine -- but is there anyway to let people add web.xml for things like ServletFilters without manully unpacking and modifyng hte war? ...if there is, we should look into it for stuff like this, and now is a good time to start. ...if not, then we need to be cautious about not bloating Solr -- but the functionality of this patch seems to be worthwhile. -Hoss
