You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2014/12/02 02:01:42 UTC

[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download

    [ https://issues.apache.org/jira/browse/SOLR-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230784#comment-14230784 ] 

Hoss Man commented on SOLR-6806:
--------------------------------

My broad strokes opinion on being concerned with the release sizes is simple: 

* Folks who care a lot about the num bytes they have to download should be encouraged to use the source releases and compile themselves
** as much as possible we should make it dead simple to "build" solr from source for these people with poor net connections who are concerned about saving bytes.
* the binary releases should strive for being as dead simple to use as possible, since their target user is a novice who doesn't (yet) know/understand what they need/want.
** if that means they are kind of big, because they include all contribs, that is (in my opinion) more new user friendly then having users discover after downloading & installing solr that they have to go download and install 27 other micro plugins in order to get it to do what they want.

as Doug once wisely pointed out...

bq. The reason is that you don't optimize the out-of-box experience for advanced users: it's okay to frustrate them a bit, they're going to find what they need in the download.  The more important thing is not to confuse newbies.  A single download with documentation and examples is what newbies need.  While you might be somewhat annoyed by the extra baggage, how much harder does it really make your life?

> Reduce the size of the main Solr binary download
> ------------------------------------------------
>
>                 Key: SOLR-6806
>                 URL: https://issues.apache.org/jira/browse/SOLR-6806
>             Project: Solr
>          Issue Type: Task
>          Components: Build
>    Affects Versions: 5.0
>            Reporter: Shawn Heisey
>
> There has been a lot of recent discussion about how large the Solr download is, and how to reduce its size.  The last release (4.10.2) weighs in at 143MB for the tar and 149MB for the zip.
> Most users do not need the full download.  They may never need contrib features, or they may only need one or two, with DIH being the most likely choice.  They could likely get by with a download that's less than 40 MB.
> Our primary competition has a 29MB zip download for the release that's current right now, and not too long ago, that was about 20MB.  I didn't look very deep, but any additional features that might be available for download were not immediately apparent on their website.  I'm sure they exist, but I would guess that most users never need those features, so most users never even see them.
> Solr, by contrast, has everything included ... a "kitchen sink" approach. Once you get past the long download time and fire up the example, you're presented with configs that include features you're likely to never use.
> Although this offers maximum flexibility, I think it also serves to cause confusion in a new user.
> A much better option would be to create a core download that includes only a minimum set of features, probably just the war, the example servlet container, and an example config that only uses the functionality present in the war.  We can create additional downloads that offer additional functionality and configs ... DIH would be a very small addon that would likely be downloaded frequently.
> SOLR-5103 describes a plugin infrastructure which would make it very easy to offer a small core download and then let the user download additional functionality using scripts or the UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org