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

[Fredrik Lundh]

Phillip J. Eby wrote:

> As always, your comments and feedback are appreciated.
>      def run_with_cgi(application):
>
>          environ = {}
>          envrion.update(os.environ)

NameError

>          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

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

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

</F>