On Sun, Mar 13, 2011 at 11:47 AM, Grant Ingersoll <gsing...@apache.org> wrote: > I guess the question people w/ Solr only hats on have (if there are such > people), is which way is that street going? It seems like most people want > to pull stuff out of Solr, but they don't seem to want to put into it. > That's probably where some of the resistance comes from. If you want to > modularize everything so that you can consume it outside of Solr, it usually > means you don't use Solr, which sometimes comes across that you don't care if > the modularization actually has a negative effect on Solr. I'm all for > modularization and enabling everyone, but not at the cost of loss of > performance in Solr. As tightly coupled as Solr is, it's pretty damn fast > and resilient. Show me that you keep that whole and I'll be +1 on everything.
Do you have any facts to back up these baseless accusations? Because I'll tell you how its "seems" to me: lucene committers are going well beyond whats required (fixing solr) to commit changes to lucene. Take a look at the commits list, we are the ones doing Solr's dirty work: * Like Uwe Schindler fixing up tons of XML related bugs in Solr, fixing analysis.jsp and the related request handlers. * Like Simon Willnauer doing the necessary improvements to IndexReader such that SolrIndexReader need not exist, and trying to add good codec support to Solr so it can take advantage of flexible indexing. And I guess i didnt "put any effort into solr" when i spent a huge chunk of this weekend tracking down jre crashes and test bugs in a Solr cloud test?! As far as modularization having a negative performance effect on Solr, how is this the case? Again do you have any concrete examples, or is this just more baseless accusations? Do you have specific benchmarks to where solr's analysis is now somehow slower due to the refactoring (since this is the only modularization thats happened from solr)?! Doesn't look slower to me: http://www.lucidimagination.com/search/document/46a8351089a98aec/protwords_txt_support_in_stemmers#46a8351089a98aec --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
