[Twisted-web] CorePost 0.0.7 - all about content types

[Jacek Furmankiewicz]

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 <jaroslaw.fedewicz at gmail.com>

>
> 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
> Twisted-web at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-web/attachments/20111002/4659cacb/attachment.htm