lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <>
Subject Re: [VOTE] Create Solr TLP
Date Wed, 27 Apr 2011 08:08:43 GMT
-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);

Compiled with an optimistic compiler... :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message