Well, I see your point, but do not necessarily agree. As a mostly Java guy (that'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.
There is something to be said about an "all batteries included" 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's just better to leave it to a hand-rolled solution anyway. 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't do everything for everybody. Jacek 2011/10/1 Jarosław Fedewicz <[email protected]> > > On Oct 1, 2011, at 21:51 , Jacek Furmankiewicz wrote: > > > Well, I plan to look at out-of-the-box support for: > > > > [snip] > > Jacek > 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. > > 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'll never ever need. > > 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... > > 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't work in the enterprise environment like "Hey, let'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's a big reason behind Jython'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. > > > _______________________________________________ > Twisted-web mailing list > [email protected] > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web >
_______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
