lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: modularization discussion
Date Thu, 28 Apr 2011 00:50:43 GMT

On Apr 26, 2011, at 11:12 PM, Chris Male <> wrote:

> > The two sides/takes seem to be (with some example reasons):
> > 1. pro: for example, modularization can expose features that were
> > traditionally in solr to lucene users.
> Some other Pros:
> Easier to test individual pieces.  Easier to benchmark.
> More usage == more/better features/functionality for everyone.
> Easier for people to contribute to without having to know the full stack.
> I think most people agree that decoupled, reusable modules are a good thing in general
as an abstract concept, but, of course, specifics matter.
> > 2. con: for example, modularization slows development of these
> > features and they will evolve slower if they are in lucene.
> >
> I think this needs a bit more explanation.  AIUI, the primary cause for concern is that
by making something a module, you are taking a private, internal API of Solr's and now making
it a public API that must be maintained (and backwards maintained) which could slow down development
as one now needs to be concerned with more factors than you would if it were merely an implementation
detail in Solr.
> I feel this can be flipped around and seen as a pro though too.  

Agreed. Wasnt sure where to put it. Some see it as bad, some as good

> Taking internal code and making it public can be beneficial for that code, because it
forces the APIs to be examined, test coverage improved, and a general 'kicking of the tyres'.
 With private internal APIs, there is always a temptation to make quick changes that meet
an immediate need, rather than having to step back and take more time considering changes.
 That can slow things down yes, but it definitely has its benefits.
> Other Cons:
> The concern was that Solr just becomes an uninteresting, empty shell that glues together
modules. (I don't agree, but wanted to present what I have heard)
> > I think we need to somehow get a better understanding of both sides,
> > specific examples of portions of the code would be helpful I think.
> > Maybe then we can arrive at a compromise so that we aren't so
> > frustrated about this issue.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> -- 
> Chris Male | Software Developer | JTeam BV.|

View raw message