I'm catching up on mail, and what like to throw another monkey wrench /straw man into the mix for consideration...
: I guess the main point that I want to interrogate a bit is: do we : *really* need the ability for folks to customize these built-ins on a : core-by-core basis? Or are we designing for a use-case that may not : exist in practice? Someone disabling (e.g.) CSV everywhere for : security reasons makes sense to me. But it's harder for me to picture : a case where a user would absolutely *need* to disable one of our : built-ins, but only on select cores. Have we seen that in the field : anywhere? What if we take a step back, and start focusing more on using SPI for "finding" and registering more plugins? Not just in terms of finding plugins "by name" but also finding *implicit* plugins "by type" At which "FooBarBazRequestHandler" could live in it's own module but could *ALSO* be implicit if that module is loaded at run-time. So solr could say "The recommended SOLR_MODULES are xml,csv,json,..." and if you load those then ever collection will implicitly have request handlers like /update/xml, /update/csv, update/json (and their underlying ContentStreamLoaders for /update) and response writers like wt=xml, wt=csv, wt=json. But if you *DON'T* include those modules at runtime, then they won't be implicit. (Plus all the current options: if you explicitly declare a handler/responsewriter/etc with a name & a class, then the SolrCore won't load unless the class can be found, and that name will be bound to it even if an "implicit" handler -- that is in a loaded module -- would typically use that name) -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
