[Twisted-Python] When can I start using web2?

[James Y Knight]

On Oct 5, 2005, at 11:23 AM, Alex Levy wrote:
> Glyph's first point is extremely valid: web2 needs to be a
> fully-featured server. That means, in my mind, everything that
> twisted.web does, then something more. It might be that web2 supports
> all of that already, but if so, that support isn't documented very  
> well

It has some documentation, but of course, it certainly needs more. It  
doesn't yet do everything that twisted.web does. One glaring omission  
is a HTTP client. Another is auth/cookies. I'm working on the first.

> A list of things I haven't seen out of web2 yet:
>
> * Painless web server deployment.

Not done. There is no ready-made server included.

> * File uploads.

Should work, needs documentationing. Summary: fileupload.py is the  
low level functionality that you usually don't need to call directly.  
server.parsePOSTData is the "normal" interface into this system,  
which is what resource.PostableResource calls when confronted with a  
POST. It does what you want most of the time: incrementally parsing  
the form fields into request.args and request.files, putting the  
files in temp files on disk, with some limits on the file size  
(customization of said limits should be pushed out to the toplevel  
functions but hasn't been). request.args is a dict of {fieldname:  
valuestring}, request.files is a dict of {fieldname: (filename,  
content-type, TemporaryFile-instance)}.

> More importantly, how can it be added to a twisted.web
> application that is being migrated? Can it be added piecemeal?

Not entirely sure what you mean, but, the new parsing code is invoked  
when you use a twisted.web resource in a twisted.web2 server.

> * Clear migration path from an existing twisted.web application.
> If I've written an application that has old-style resources, do I even
> have an upgrade path?

Yes, web2 supports old web1 resource hierarchies inside web2 resource  
hierarchies, run by a web2 server.

> What about twisted.web.distrib?

It ought to work with web2.

> A lot of people
> use this, especially with sockets; what's the web2 equivalent?

SCGI should work for that purpose. Eventually, any one of HTTP, SCGI,  
or FastCGI should work for that purpose, but as of yet there is no  
HTTP or FastCGI client implementation.

> * Clear migration path from an existing Nevow application.
> If I have a Nevow site, a set of resources, and an application that
> revolves around them, and I want to start using web2, where do I  
> start?

You don't, yet. While there is currently a working migration path to  
web2 from web1, the migration path from Nevow is so far nonexistent.  
There will have to be one. "Valentino Volonghi aka Dialtone" was  
working on something, but I have not really put any time into it.

> * Comparison of major design changes.
> What the heck does the streams module do?

It has a giant docstring at the top; was it unclear or did you miss it?

> What's different about the appserver, context,
> requests, static files, or virtual hosts?

The margins of my email-client are too small to answer. ;) Probably  
the most interesting difference from Nevow is the Resource/Request API.

James