Torsten Curdt a écrit : >> We use some commons projects in one of our commercial products that >> uses in-browser applets. Size is very important for some of our >> customers who have clients connecting in from geographically remote >> outstations over links with about as much bandwidth as a piece of wet >> string. >> >> We ship the workstations with the JRE installed so that's never a >> problem, but maintaining a connection long enough for the browser >> download and cache all the necessary jars almost always is. >> >> Note that I'm not opposed to a consolidated commons distribution, it's >> just that you should understand why size does matter for some >> applications. > > Sure, but how many users have that requirement? More than 1%?
Even if it is 1%, it's worth considering. I am really not comfortable with project addressing only the 80% more frequent cases. Minority should never be neglected. It's clearly a philosophical and personal choice. Luc > > Someone that cares about jar sizes can easily use the right tools to > reduce the footprint. IMO jar size should be less of a concern. > > That said I am still not sure what to make out the proposal. > > Less jar juggling - sure ...but also more dependencies of what needs > to be fixed before a release. > Plus (I am sure) people will be complaining that they "don't need all > this stuff" - which is not that great from Commons' image point of > view. > > cheers > -- > Torsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
