[Twisted-Python] web2 -> web ToDo List
While I see tickets in the tracker for web2 and others for web, I couldn't find a 'cherry pick' list of things to be moved from web2 back into web. Is there one? Thanks, S
On 4 Feb, 09:16 pm, ssteinerx@gmail.com wrote:
While I see tickets in the tracker for web2 and others for web, I couldn't find a 'cherry pick' list of things to be moved from web2 back into web.
Is there one?
Not really. It'd be great to have such a list. Any time anyone brings up their use of web2, I ask them what features it provides that caused them to select it or prevent them from switching to Twisted Web. One answer that a lot of people give is streaming access to uploads (which Twisted Web indeed makes very inconvenient now). There's a ticket for this, #288. The other answers people tend to give are "I don't know" or "nothing in particular". Sometimes they also say "HTTP/1.1 support", but when further questioned about this, they can't actually explain what that means. So, the list of tickets for Web2 -> Web "backporting" seems to currently be: - #288 Jean-Paul
On 6 Feb 2010, 17:34, exarkun@twistedmatrix.com wrote:
On 4 Feb, 09:16 pm, ssteinerx@gmail.com wrote:
While I see tickets in the tracker for web2 and others for web, I couldn't find a 'cherry pick' list of things to be moved from web2 back into web.
Is there one?
Not really. It'd be great to have such a list. Any time anyone brings up their use of web2, I ask them what features it provides that caused them to select it or prevent them from switching to Twisted Web. One answer that a lot of people give is streaming access to uploads (which Twisted Web indeed makes very inconvenient now). There's a ticket for this, #288. The other answers people tend to give are "I don't know" or "nothing in particular". Sometimes they also say "HTTP/1.1 support", but when further questioned about this, they can't actually explain what that means.
I also depend on 100-Continue support. This is somehow related to #288, but not explicitly mentioned. If one wants to stream POST data, it's better to have 'expect/continue' working. It allows to check various conditions, including authentication before allowing the client to proceed. Regards, Valeriy
On 05:06 pm, valeriy.zamarayev@gmail.com wrote:
On 6 Feb 2010, 17:34, exarkun@twistedmatrix.com wrote:
On 4 Feb, 09:16 pm, ssteinerx@gmail.com wrote:
While I see tickets in the tracker for web2 and others for web, I couldn't find a 'cherry pick' list of things to be moved from web2 back into web.
Is there one?
Not really. It'd be great to have such a list. Any time anyone brings up their use of web2, I ask them what features it provides that caused them to select it or prevent them from switching to Twisted Web. One answer that a lot of people give is streaming access to uploads (which Twisted Web indeed makes very inconvenient now). There's a ticket for this, #288. The other answers people tend to give are "I don't know" or "nothing in particular". Sometimes they also say "HTTP/1.1 support", but when further questioned about this, they can't actually explain what that means.
I also depend on 100-Continue support. This is somehow related to #288, but not explicitly mentioned. If one wants to stream POST data, it's better to have 'expect/continue' working. It allows to check various conditions, including authentication before allowing the client to proceed.
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. Jean-Paul
On Sat, Feb 6, 2010 at 11:23 AM,
On 05:06 pm, valeriy.zamarayev@gmail.com wrote:
On 6 Feb 2010, 17:34, exarkun@twistedmatrix.com wrote:
On 4 Feb, 09:16 pm, ssteinerx@gmail.com wrote:
While I see tickets in the tracker for web2 and others for web, I couldn't find a 'cherry pick' list of things to be moved from web2 back into web.
Is there one?
Not really. It'd be great to have such a list. Any time anyone brings up their use of web2, I ask them what features it provides that caused them to select it or prevent them from switching to Twisted Web. One answer that a lot of people give is streaming access to uploads (which Twisted Web indeed makes very inconvenient now). There's a ticket for this, #288. The other answers people tend to give are "I don't know" or "nothing in particular". Sometimes they also say "HTTP/1.1 support", but when further questioned about this, they can't actually explain what that means.
I also depend on 100-Continue support. This is somehow related to #288, but not explicitly mentioned. If one wants to stream POST data, it's better to have 'expect/continue' working. It allows to check various conditions, including authentication before allowing the client to proceed.
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.
Jean-Paul
This page: http://www.jmarshall.com/easy/http/ seems like it might be a good guide to upgrading to HTTP 1.1. See the section entitled "Upgrading to HTTP 1/1". :) Kevin Horn
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. Is there a way to backport the web2 system and retain backward compatibility with existing user code? 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. -- dkeeney@travelbyroad.net Rdbhost -> SQL databases as a webservice [www.rdbhost.com]
On 05:21 pm, dvkeeney@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
participants (5)
-
David -
exarkun＠twistedmatrix.com -
Kevin Horn -
ssteinerX＠gmail.com -
Valeriy Zamarayev