lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <simon.willna...@googlemail.com>
Subject Re: [VOTE] Create Solr TLP
Date Wed, 27 Apr 2011 08:29:08 GMT
On Wed, Apr 27, 2011 at 10:08 AM, Doron Cohen <cdoronc@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

Mime
View raw message