Opened 8 years ago

Last modified 5 months 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:
Author:

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 8 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 6 years ago by glyph

  • Description modified (diff)

comment:3 Changed 6 years ago by <automation>

  • Owner jknight deleted

comment:4 Changed 6 years ago by washort

  • Resolution set to wontfix
  • Status changed from new to closed

comment:5 Changed 6 years ago by washort

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:6 Changed 5 months ago by adiroiban

+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.