On Apr 26, 2011, at 11:12 PM, Chris Male <gento...@gmail.com> 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: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > -- > Chris Male | Software Developer | JTeam BV.| www.jteam.nl
