[Web-SIG] Re: The rewritten WSGI pre-PEP

[Phillip J. Eby]

At 01:04 PM 8/11/04 +0200, Fredrik Lundh wrote:
>Phillip J. Eby wrote:
>
> > As always, your comments and feedback are appreciated.
> >      def run_with_cgi(application):
> >
> >          environ = {}
> >          envrion.update(os.environ)
>
>NameError

[added to to-do list]


> >          environ['wsgi.input']        = sys.stdin
> >          environ['wsgi.errors']       = sys.stderr
> >          environ['wsgi.version']      = '1.0'
> >          environ['wsgi.multithread']  = False
> >          environ['wsgi.multiprocess'] = True
>
>The answer's probably hidden somewhere in the mailing list archives, but why
>do you mix WSGI variables with external CGI environment variables?
>
>I'd prefer
>
>      def application(context, environ, start_response)
>
>where context is an object of a server-defined type, with attributes for
>input, errors, etc:
>
>             context = MyApplicationServerContext()
>             context.input = sys.stdin
>             context.errors = sys.stderr
>             context.version = "1.0" (or (1, 0))
>             etc
>
>Advantages:
>- contexts can (probably) be reused
>- attributes can be lazily initialized (via properties or getattr hooks)
>- the user code looks nicer
>- future safe: more attributes and methods can be added to the context
>   object in future revisions of this specification, without changing the
>   function signatures

All of these advantages also apply to an object supplied in the dictionary, 
i.e.:

     environ['some_server.context'] = context_object


>Disadvantages:
>- one more argument; but if that's really a problem, why not make
>   start_response a method of the context class?
>
>         def application(context, environ):
>             ...
>             context.start(status, headers)

The advantage is simplicity of implementation.  It's possible to write 
middleware (application that's also a server) without creating any new 
classes.  In essence, WSGI is an almost pure-functional architecture, which 
makes it (IMO) easier to reason about.



> > The second parameter passed to the application object is itself a
> > two-argument callable, used to begin the HTTP response and return
> > a ``write()`` function.  The first parameter it takes is a "status"
> > string, of the form ``"999 Message here"``, where ``999`` is replaced
> > with the HTTP status code, and ``Message here`` is replaced with the
> > appropriate message text.
>
>To make life easier for users, you might wish to accept either an integer
>status code (e.g. start(200, headers)) or a string.  In case a status code
>is provided, the server can fill in a suitable string value (as per the HTTP
>specification).

I thought about this, but the diffference between '200' and '"200 OK"' is 
so trivial as to be unuseful compared to the scope creep for the server's 
implementation.  That is, allowing this means the server software has to 
have a list of the numeric statuses, versus an application author looking 
up the few that they actually want to use.  Also, web frameworks often 
already have such a lookup table, so it seems to me that putting the 
responsibility on the application side is the better balance.


>Except for those small nits, I'm totally +1 on this proposal.

Thanks.  I'll add your questions to the Q&A section.