On Wed, Apr 27, 2011 at 10:08 AM, Doron Cohen <[email protected]> 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
