Given that these are all public, we mustn't break compatibility with code that invokes them with existing resource objects, as long as those resource objects return resources synchronously. So we could either do a bunch of conditionals to make sure we return resource objects synchronously when no deferreds are returned, or we could just come up with a separate implementation of Request.process that uses a different codepath entirely. If we do the latter, we must make sure we maintain compatibility with users utilizing the various resource hooks.

Change History (6)

I take issue with the summary "allow getChild to return a Deferred". I think the real idea here is to allow Deferreds to be returned during resource traversal, regardless of what method is used :). One of the options here to maintain compatibility — my preferred option, actually — is to come up with a new method name and deprecate getChildWithDefault().

Another option would be to have getChildWithDefault always return a DeferredResource when getChild returns a Deferred.

We also have twisted.web.util.DeferredResource which I think is trying to work around this problem, but a cleaner API is better.

I think that a new traversal method is also needed in order to support HTTP continue functionality... so if this is implemented before the HTTP continue functionality it would be nice to allow the new traversal code to be called after all headers have been parsed rather than after all the body was consumed.

I think that we need an umbrella ticket to list of the problems with the current web API and gather feedback for how to improve it.

I remember that were also talks about creating separate Request - Response objects