Well, I see your point, but do not necessarily agree.<div><br></div><div>As a mostly Java guy (that&#39;s what I do at work 90% of the time), I deal daily with the complexity of these dozens of tiny little libs that you can assemble...as a result my Maven pom.xml file is hundreds of lines long.</div>
<div><br></div><div>There is something to be said about an &quot;all batteries included&quot; approach that handles 80% of the most common use cases out of the box. Handling the other 20% often entails so much more additional complexity, that maybe it&#39;s just better to leave it to a hand-rolled solution anyway.</div>
<div><br></div><div>Django rolls a lot of things into one complete package...and that is the reason we are slowly moving all of our Java / .Net code to it (for web development). There is value to this level of integration, even if it doesn&#39;t do everything for everybody.</div>
<div><br></div><div>Jacek<br><br><div class="gmail_quote">2011/10/1 Jarosław Fedewicz <span dir="ltr">&lt;<a href="mailto:jaroslaw.fedewicz@gmail.com">jaroslaw.fedewicz@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Oct 1, 2011, at 21:51 , Jacek Furmankiewicz wrote:<br>
<br>
&gt; Well, I plan to look at out-of-the-box support for:<br>
&gt;<br>
</div>&gt; [snip]<br>
&gt; Jacek<br>
Again, there is such thing as concern separation. I would welcome all those as separate packages, but if CorePost made me do extra work to keep irrelevant bits out, it would be useless. It would be far more simple then for me to roll my own library which would just serve web requests and do no more than that.<br>

<br>
Let me stress. A separate package that does web serving. A separate one for load balancing proxy. A separate one to work with AMPoule. A separate one to work with ZeroMQ. Not all-in-one blob which has all the shiny bits included there just in case which I&#39;ll never ever need.<br>

<br>
If I were you, I would even separate data formats support (XML/JSON/YAML/whatever else is there). Just provide an interface every data format adapter must implement. There might be people who would want ASN.1, like it or not...<br>

<br>
The reason is simple, your users might have their own libraries and solutions, there might be even actual reasons for them to have them, and it just doesn&#39;t work in the enterprise environment like “Hey, let&#39;s add a bunchload of these cool 3rd party libraries just in case”. They might have a load-balancing infrastructure of their own in place, Twisted or not. They might actually *prefer* nginx for some reason. They might have other libraries to do data formats handling (there&#39;s a big reason behind Jython&#39;s existence, namely, have all those funky Java libraries here and now). What they face would be supporting two different process management infrastuctures instead of one, or support two libraries which basically do one thing, instead of one library. This is going to be at least as twice as expensive, if not even more expensive if you ever try to glue those things together and get them to play nicely with one another.<br>

<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Twisted-web mailing list<br>
<a href="mailto:Twisted-web@twistedmatrix.com">Twisted-web@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web</a><br>
</div></div></blockquote></div><br></div>