[Twisted-Python] web2 -> web ToDo List

[exarkun at twistedmatrix.com]

On 05:21 pm, dvkeeney at gmail.com 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. :)

Jean-Paul