: Another important driver is the "out-of-the-box experience". I honestly have no idea what an OOTB experience for Lucene-Java means ... For Solr i understand, For Nutch i understand ... for a java library????
The closest thing we can do to describing an OOTB experience is making a good demo ... and there's no reason the demo can't utilize contrib jars and tweak settings to be better tuned then the default (if the default is the way it is for back-compat reasons) : It's crucial that Lucene has good starting defaults for everything : because many developers will stick with these defaults and won't : discover the wiki page that says you need to do X, Y and Z to get : better relevance, indexing speed, searching speed, etc. This then : makes Lucene look bad, not only to these Lucene users but then also to : the end users who use their apps that say "Powered by Lucene". Butthen we get into that back-compat concern issue. Sith something like Solr, we have hardcoded defaults and then we have recommeded setings. the recommended settings go in the example configs that ship with every release, but we leave the hardcoded defaults as backwards compatible as possible except in extreme cases -- in those cases, we make sure there's a simple setting to restore the old behavior. For a library like Lucene-Java, the nearest equivilent i can think of is a global properties file (eeecch) or some static factories for producing objects that have different compatibility garuntees. id: Similarity.getDefaultSimilarity() is garunteed to allways return an equivilent Similiarity impl for all 1.X releases, but Similarity.getRecommendedSimilarityForShortText() might change btween every release; dito for things like "new StandardAnalyzer(...)" vs "Analyzer.getRecommendedAnalyser(...) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
