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
