diff options
| author | termie <github@anarkystic.com> | 2011-03-24 16:38:31 -0700 |
|---|---|---|
| committer | termie <github@anarkystic.com> | 2011-03-24 16:38:31 -0700 |
| commit | e3dfae1bba0e4f9ff5d64ff5fadb43485e494453 (patch) | |
| tree | 31ce263ca37ccfa36a32ee6040e5fb6702a5597b /nova | |
| parent | 9da833ff9298a00ba33ca67885a7a663a3b9e35f (diff) | |
add descriptive docstring
Diffstat (limited to 'nova')
| -rw-r--r-- | nova/objectstore/s3server.py | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/nova/objectstore/s3server.py b/nova/objectstore/s3server.py index 83ca5bfa3..dd6327c8f 100644 --- a/nova/objectstore/s3server.py +++ b/nova/objectstore/s3server.py @@ -82,6 +82,38 @@ class S3Application(wsgi.Router): class BaseRequestHandler(wsgi.Controller): + """Base class emulating Tornado's web framework pattern in WSGI. + + This is a direct port of Tornado's implementation, so some key decisions + about how the code interacts have already been chosen. + + The two most common ways of designing web frameworks can be + classified as async object-oriented and sync functional. + + Tornado's is on the OO side because a response is built up in and using + the shared state of an object and one of the object's methods will + eventually trigger the "finishing" of the response asynchronously. + + Most WSGI stuff is in the functional side, we pass a request object to + every call down a chain and the eventual return value will be a response. + + Part of the function of the routing code in S3Application as well as the + code in BaseRequestHandler's __call__ method is to merge those two styles + together enough that the Tornado code can work without extensive + modifications. + + To do that it needs to give the Tornado-style code clean objects that it + can modify the state of for each request that is processed, so we use a + very simple factory lambda to create new state for each request, that's + the stuff in the router, and when we let the Tornado code modify that + object to handle the request, then we return the response it generated. + This wouldn't work the same if Tornado was being more async'y and doing + other callbacks throughout the process, but since Tornado is being + relatively simple here we can be satisfied that the response will be + complete by the end of the get/post method. + + """ + def __init__(self, application): self.application = application |
