| From | Sent On | Attachments |
|---|---|---|
| Robert Muir | Apr 26, 2011 8:07 pm | |
| Yonik Seeley | Apr 26, 2011 8:34 pm | |
| Grant Ingersoll | Apr 26, 2011 8:41 pm | |
| Chris Male | Apr 26, 2011 9:12 pm | |
| Robert Muir | Apr 26, 2011 9:14 pm | |
| Michael McCandless | Apr 27, 2011 3:27 am | |
| Michael McCandless | Apr 27, 2011 3:36 am | |
| Mark Miller | Apr 27, 2011 5:12 am | |
| Robert Muir | Apr 27, 2011 5:33 am | |
| Steven A Rowe | Apr 27, 2011 6:18 am | |
| Yonik Seeley | Apr 27, 2011 6:24 am | |
| Steven A Rowe | Apr 27, 2011 6:48 am | |
| Michael McCandless | Apr 27, 2011 8:49 am | |
| Grant Ingersoll | Apr 27, 2011 5:50 pm | |
| Yonik Seeley | Apr 27, 2011 6:23 pm | |
| Greg Stein | Apr 27, 2011 8:44 pm | |
| Grant Ingersoll | May 2, 2011 3:11 pm | |
| Ryan McKinley | May 2, 2011 4:31 pm | |
| Mark Miller | May 2, 2011 7:27 pm | |
| Michael McCandless | May 3, 2011 9:49 am | |
| Michael McCandless | May 3, 2011 9:55 am | |
| Mark Miller | May 3, 2011 10:11 am | |
| Shai Erera | May 3, 2011 10:29 am | |
| Ryan McKinley | May 3, 2011 10:31 am | |
| Mark Miller | May 3, 2011 10:46 am | |
| Michael McCandless | May 4, 2011 5:25 am | |
| Mark Miller | May 4, 2011 6:10 am | |
| Robert Muir | May 4, 2011 6:29 am | |
| Uwe Schindler | May 4, 2011 6:41 am | |
| Mark Miller | May 4, 2011 6:49 am | |
| Simon Willnauer | May 4, 2011 7:01 am | |
| Simon Willnauer | May 5, 2011 1:15 am | |
| Grant Ingersoll | May 5, 2011 7:25 am | |
| Mark Miller | May 5, 2011 7:40 am | |
| Simon Willnauer | May 5, 2011 8:03 am | |
| Grant Ingersoll | May 5, 2011 8:34 am | |
| Jason Rutherglen | May 5, 2011 9:58 am | |
| Chris Hostetter | May 6, 2011 1:35 pm | |
| Mark Miller | May 6, 2011 1:44 pm | |
| Michael McCandless | May 7, 2011 3:30 am | |
| Simon Willnauer | May 7, 2011 3:34 am | |
| Michael McCandless | May 7, 2011 3:45 am | |
| Michael McCandless | May 7, 2011 4:01 am | |
| Simon Willnauer | May 7, 2011 4:10 am | |
| Grant Ingersoll | May 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.
-- Chris Male | Software Developer | JTeam BV.| www.jteam.nl





