We want twisted.web to have better unit tests, and we also want to be able to use twisted.web request-processing code easily in our unit tests for our resources. We should improve this situation by separating the concerns in request processing to allow using fewer parts of it at once.

The change proposed here is basically separating the concepts of Request and Response, and moving the data serialization code to the HTTP Channel (i.e. the protocol implementation).

This is kind of a major change for twisted.web, but we would like to do it without breaking backwards compatibility.

The idea is that the HTTP Channel will pass requests off to its "HTTP Request Receiver" object. This will likely be the L{twisted.web.server.Site}. This will look up a resource for the request, render it, and return a Response object. The channel will then tell the response to write its body to the channel; the response will write the data (optionally registering itself as a producer) to the channel in a protocol-agnostic manner (i.e., chunking and stuff will be the responsibility of the channel).

At the end of this change, Request should have no required parameters. Of course, it will still remain compatible with guys who pass arguments to it, and directly call request.write and request.finish; these will be implemented by creating a BackwardsCompatibilityResponse at request._bcResponse. request.write and request.finish will probably require having a request that had a channel passed to it.