On Wed, Apr 27, 2011 at 10:08 AM, Doron Cohen <cdor...@gmail.com> wrote: > -1 for unmerge. > > Another thing to keep in mind is that Solr can be considered not just "an >> application that uses Lucene", but rather the *ideal* application layer for >> Lucene. Solr is basically an awesome example of what Lucene can be used for >> in an application. Every feature that Lucene supports, should be available >> through Solr. The opposite (that every Solr feature should be available via >> Lucene) depends on the feature and can't be stated as a general rule. >> > ... > >> So, what makes sense to me is to allow Solr developers to create features >> for the application in whatever manner is most sensible for the application >> need. Those features should be added to the Solr project. Then, for each of >> those new features, have a discussion (and subsequently a proper Apache >> vote) to determine whether or not this feature should be a library layer >> feature or not. Once it's decided that it should be, an appropriate >> generalized design should be proposed, agreed upon, then implemented in >> Lucene. Once that is finished, the Solr feature can be updated to use the >> new functionality from Lucene. >> > ... > >> If at any point this is not working out for Solr, the application layer can >> change the implementation to be what it needs to be, and then start a >> discussion about how the library layer implementation can be updated to >> support that. >> >> Following that process, I really don't see a conflict at all. >> > > The above quite summarizes my opinion on this. > > It really is a win-win: > - Generalization (modules) should not block Solr > - Solr helps improving Lucene > - Solr has the privilege of guiding Lucene about which features to develop > and how > > while(true) { > f = app.develop-new-great-feature(); > if (is-a-general-interest-feature(f)) { > g = generalize-feature(f); > m = port-to-modules(g); > f2 = app.rewrite-based-on-modules(f,m); > app.replace-impl(f,f2); > } > } > > Compiled with an optimistic compiler... :) > > Doron > here is a patch to make it more realistic
while(true) { f = app.develop-new-great-feature(); if (is-a-general-interest-feature(f)) { - g = generalize-feature(f); + try { + g = generalize-feature(f); + } catch (YonikDoesntLikeItException ex) { + continue; + } m = port-to-modules(g); f2 = app.rewrite-based-on-modules(f,m); app.replace-impl(f,f2); } } sorry for the sarcasm, simon