: Well sure, Solr is no webapp framework. But you can do some things with the : ShowFileRequestHandler, like have static textual content (like CSS and
While i think it's definitely important to have some basic admin functionality available in the war, at a certain point we should really just focus on making sure there's a good HTTP/XMl/JSON based API for everything, and perhaps distribute the Admin console as a seperate webapp (or perhaps not even a webapp, maybe just a collection of HTML files that use AJAX to do everything) ShowFileRequestHandler can take you pretty far, but eventually you either have to say "put this big hunk of stuff in your solrcofig.xml or it won't work" or you have to have the admin tool inspect hte core to get a lot of data it needs to build up the admin pages -- so let's just expose all that data via XML/JSON and (ie: registry.jsp on steriods) and then any external tool (built by us in velocity, built by someone else in ruby, built by several differnet people to integrate into several differnet tools) can use it to get the metadata it needs to drive tool behavior. I had some notes along htese lines once, ... ah yes ... http://wiki.apache.org/solr/MakeSolrMoreSelfService ...some of that stuff has already come to pass, and the rest is pretty out of date with how we do things now, but the idea of having a clean API to discover what handlers a given solr port exposes, and what params that instance of those handlers say they accept is still a really good idea. in the context of this discussion it's a little differnet because we're taling specificly about hte CoreAdminHandler -- but hte principle is hte same. -Hoss
