Opened 13 years ago

Last modified 5 years ago

#3621 enhancement reopened

twisted.web should allow getChild to return a Deferred.

Reported by: radix Owned by:
Priority: normal Milestone:
Component: web Keywords:
Cc: Branch:

Description (last modified by Glyph)

This potentially requires changes to a number of public APIs:

  • resource.IResource.getChildWithDefault
  • resource.getChildForRequest
  • resource.Resource.getChildWithDefault
  • resource.Resource.getChild
  • server.Site.getChildWithDefault
  • server.Site.getResourceFor

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.

Related: #3711

Change History (6)

comment:1 Changed 13 years ago by Glyph

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.

comment:2 Changed 11 years ago by Glyph

Description: modified (diff)

comment:3 Changed 11 years ago by <automation>

Owner: jknight deleted

comment:4 Changed 11 years ago by washort

Resolution: wontfix
Status: newclosed

comment:5 Changed 11 years ago by washort

Resolution: wontfix
Status: closedreopened

comment:6 Changed 5 years ago by Adi Roiban

+1 for introducing a new traversal method and deprecating the others.

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

Note: See TracTickets for help on using tickets.