atom feed45 messages in org.apache.lucene.solr-devRe: modularization discussion
FromSent OnAttachments
Robert MuirApr 26, 2011 8:07 pm 
Yonik SeeleyApr 26, 2011 8:34 pm 
Grant IngersollApr 26, 2011 8:41 pm 
Chris MaleApr 26, 2011 9:12 pm 
Robert MuirApr 26, 2011 9:14 pm 
Michael McCandlessApr 27, 2011 3:27 am 
Michael McCandlessApr 27, 2011 3:36 am 
Mark MillerApr 27, 2011 5:12 am 
Robert MuirApr 27, 2011 5:33 am 
Steven A RoweApr 27, 2011 6:18 am 
Yonik SeeleyApr 27, 2011 6:24 am 
Steven A RoweApr 27, 2011 6:48 am 
Michael McCandlessApr 27, 2011 8:49 am 
Grant IngersollApr 27, 2011 5:50 pm 
Yonik SeeleyApr 27, 2011 6:23 pm 
Greg SteinApr 27, 2011 8:44 pm 
Grant IngersollMay 2, 2011 3:11 pm 
Ryan McKinleyMay 2, 2011 4:31 pm 
Mark MillerMay 2, 2011 7:27 pm 
Michael McCandlessMay 3, 2011 9:49 am 
Michael McCandlessMay 3, 2011 9:55 am 
Mark MillerMay 3, 2011 10:11 am 
Shai EreraMay 3, 2011 10:29 am 
Ryan McKinleyMay 3, 2011 10:31 am 
Mark MillerMay 3, 2011 10:46 am 
Michael McCandlessMay 4, 2011 5:25 am 
Mark MillerMay 4, 2011 6:10 am 
Robert MuirMay 4, 2011 6:29 am 
Uwe SchindlerMay 4, 2011 6:41 am 
Mark MillerMay 4, 2011 6:49 am 
Simon WillnauerMay 4, 2011 7:01 am 
Simon WillnauerMay 5, 2011 1:15 am 
Grant IngersollMay 5, 2011 7:25 am 
Mark MillerMay 5, 2011 7:40 am 
Simon WillnauerMay 5, 2011 8:03 am 
Grant IngersollMay 5, 2011 8:34 am 
Jason RutherglenMay 5, 2011 9:58 am 
Chris HostetterMay 6, 2011 1:35 pm 
Mark MillerMay 6, 2011 1:44 pm 
Michael McCandlessMay 7, 2011 3:30 am 
Simon WillnauerMay 7, 2011 3:34 am 
Michael McCandlessMay 7, 2011 3:45 am 
Michael McCandlessMay 7, 2011 4:01 am 
Simon WillnauerMay 7, 2011 4:10 am 
Grant IngersollMay 7, 2011 5:20 am 
Subject:Re: modularization discussion
From:Chris Male (gent@gmail.com)
Date:Apr 26, 2011 9:12:11 pm
List:org.apache.lucene.solr-dev

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.