On Sun, Jan 08, 2017 at 07:34:53PM -0500, Jean-Paul Calderone wrote: > Hi Mark, > > Thanks for tackling this long-standing issue! >
I hope I actually make some progress :) > > He also noted that the Request interface with which HTTPChannel > > interacts is mostly not described by twisted.iweb.IRequest. That > > means we can augment the ways HTTPChannel talks to Request-like > > things without breaking many public APIs. > > > > > How will this affect applications which have implemented Request-alike > classes (for example, for testing purposes)? The interface may not be > explicitly defined as a Zope Interface right now but it is defined by the > current implementation and it is largely public (ie, non-_-prefixed > names). Tests may have hooked in to parts of Request not documented by > IRequest out of necessity. It would be a shame to break such carefully > crafted automated tests. > The new streaming request interface will define how HTTPChannel talks to a completely separate Request-like implementation. HTTPChannel can then inspect what interface is provided by the object returned from its requestFactory and either use the existing code path or the new streaming one. The default requestFactory will remain twisted.web.http.Request. These things taken together should mean that existing code doesn't need to change at all. I hope to use Twisted's own tests to verify this, but I might use Flocker's as well. I'd like to point out that this approach means that defining _IDeprecatedHTTPChannelToRequestInterface isn't strictly necessary. I'd like to do so anyway to help me track the existing API so I'm less likely to break it, and to make the dispatch logic in HTTPChannel more robust. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python