On 05:21 pm, firstname.lastname@example.org wrote:
Awesome, thanks for adding to the list. :) �Now that there are two items on it, I've added a section to the end of http://twistedmatrix.com/trac/wiki/TwistedWebPlan. �I encourage anyone with interest in this area to suggest more items for this list.
Does nobody care about web2's rational separation of Request and Response objects, or the use of header dictionaries and ByteStreams in the response?
The approach used in web (render() returning a string or a 'NOT_DONE_YET' and then writing through the request and calling finish() IIRC) is clunky and confusing.
Separation of Request and Response is a good idea, I think. Chris Armstrong started working on this some time ago (a year? two?) but I think the amount of work involved was more than he bargained for and as far as I know he doesn't have any specific plans to complete the work.
The ticket for that is http://twistedmatrix.com/trac/ticket/2983
There's also a ticket for allowing render to return a Deferred, #3711. And similarly, one to allow getChild to return a Deferred, #3621.
I've added links to these tickets to the TwistedWebPlan page.
The plan is to not backport the streams APIs, but instead support the existing producer/consumer APIs in more places, or to come up with streaming APIs which can be used throughout Twisted, get them into core, and then use them in Twisted Web (or perhaps do both of these).
I'm not sure what you mean when you say "use of header dictionaries".
Is there a way to backport the web2 system and retain backward compatibility with existing user code?
There should be, yes. The details depend on the specifics of the APIs, of course.
Unaware of web2 until recently, I previously subclassed web.http and web.server to implement upload streaming, and found myself rewriting 'private' methods. 'private' in this case refers to methods that are commented as 'not intended for users'. It would be nice to expose many of the request parsing methods to users, and restructure the request parsing so that method overriding can be done cleanly.
This is similar to, but maybe more ambitious than, one of the items previously mentioned in the web2 features-to-backport list.
These comments are from a time before our current compatibility policy. Very likely they should all be deleted. If you can use or override a method without touching something that starts with an underscore, then it's public.
Another, perhaps better, argument against touching these bits is that they're probably not very well tested. However, this is easily fixed, just contribute tests (and in some cases, documentation) for them. :)