> > > 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. 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
