[Twisted-web] Nevow future
manlio_perillo at libero.it
Wed Apr 12 04:04:00 CDT 2006
glyph at divmod.com ha scritto:
>>> When there is a 1.x release, you can begin to expect things
>>> to stop changing as much.
>> There are previsions?
> What is a 'prevision'?
1) We don't have any idea of what will happen in the future
2) We have an ideal architecture and API definition in mind, but we
don't know how it will take to complete the developement
> The WSGI support may not work at all. It is unsupported, undocumented,
> and there are no tests which import it.
> The WSGI support will only realistically work in a Twisted-style
> environment. Athena depends explicitly on the reactor, so invoking any
> Athena-using applications in a non-Twisted context will not work.
> Livetest requires the reactor as well, so you will not be able to write
> nit tests for your application or use any 3rd party fragments which use
> athena or are tested in this manner.
I'm not sure of this point.
Athena depends on the reactor, but when using Nevow with Zomne, don't we
have a full twisted application running?
By the way, what about:
"""Running your Nevow applications under twisted.web also gives you
access to some of the more advanced "Live" features of Nevow, such as
nevow.livepage and nevow.canvas. Currently, these modules require more
control over the HTTP socket than CGI or WSGI can provide. (This may
change in the future.)"""
> Don't get me wrong, I would love it if there were dedicated maintainers
> for these use-cases, since I realize they are important to many people.
In my case I'm still investigating this.
lighttp is gaining popularity, so there are opportunities to have it
available on many hosting solutions.
> They just aren't important to *us*, so we're not going to spend time.
>>> Your Nevow applications should remain independent of it, though.
>> I would like to use lighttp as the *only* webserver, and Nevow *only*
>> for the rendering, session support, and so.
> lighttpd supports reverse proxies. Nevow's session support, in
> nevow.guard, depends on the reactor and twisted.web, so you will be
> unable to use it otherwise.
Just a question:
it is possible to forward an HTTP request using Unix domain sockets?
Is this supported with Apache and lighhtp?
>>>> Reverse Proxy is not an option for me (*why* to use two or more
>>>> webservers and duplicate HTTP protocol handling?).
>>> Because it solves a problem? Why *not* do this?
>> I don't like the idea.
> Yes but _WHY_ don't you like the idea?
I like the idea of a full separation between a web server and a web
> Do you live in some alternate
> reality where the arrangement of bytes in an HTTP packet has harmful
> effects but the arrangement of bytes in a FastCGI packet does not?
There is not only the question of arrangment of packets.
> This is a common mistake, because it seems "simpler" to design your own
> protocol for talking about HTTP than to use HTTP itself. It isn't. In
> fact, by definition, it cannot be: your new protocol has to provide all
> the information present in the original HTTP request (or risk breaking
> applications that depend on some information you did not relay), so in
> the best case it can be exactly as complex as HTTP.
A web server does not simply parse tha HTTP headers; it have to do some
pre and post processing.
The question is:
- what can do a web server?
- what have to do a web application?
> I wrote something
> like this in twisted.web.distrib, where I converted the HTTP requests to
> PB and back again. While the "automated proxying for users"
> functionality was cool, I had *just written* an HTTP parser and it was
> silly not to just use it over a unix socket. I am pleased to note that
> web2, when it implements something like web.distrib, will do it the
> correct way and just make it a regular reverse proxy over a unix socket.
This is interesting.
> FastCGI itself is also actually harder to parse, contains numerous
> design errors, and more confusing and inconsistent than HTTP itself.
> There are numerous inconsistencies it could have fixed in HTTP - it
> could have properly optimized the multiplexed-channel case with inband
> flow control to avoid TCP startup overhead for distant FastCGI proxies -
> it could have normalized the transport over something easy to audit and
> implement like netstrings - but it totally failed to do anything
> worthwhile despite being an entirely new protocol.
FastCGI failed because it could have been a more better protocol.
> Nevertheless, dumb as it is, supporting FastCGI is still worthwhile.
> Various bits of useful software have integrated it for one reason or
> another, and some of them don't have other ways of talking to the
> outside world. That doesn't mean it's a good idea to write new software
> that is similarly hamstrung by a bad integration decision.
> I hope I've made it clear that no, it isn't.
Thanks for the exhaustive explanation.
Regards Manlio Perillo
More information about the Twisted-web