[Web-SIG] again about logging in WSGI

[Graham Dumpleton]

On 23/11/2007, Manlio Perillo <manlio_perillo at libero.it> wrote:
> Phillip J. Eby ha scritto:
> > At 11:57 AM 11/23/2007 +0100, Manlio Perillo wrote:
> >> Hi.
> >>
> >> As I have written in a previous thread, I would like to use nginx
> >> logging system in a WSGI application (of course the same is valid for
> >> Apache)
> >>
> >> A first problem is that the wsgi.errors stream defined in the
> >> environment dictionary is valid only for the current request, but I want
> >> to use a stream valid for the entire process lifetime.
> >>
> >> I think that there are two solutions:
> >> 1) call an application supplied `init_application(environ)` callable,
> >>     where the environ dictionary contains the "right" wsgi.errors stream
> >>     object
> >> 2) add to the environ dictionary a `wsgi.global_errors` stream object
> >>
> >>
> >> Any suggestions?
> >
> > Yes: provide an 'nginx.global_errors' stream object, as a
> > server-specific extension.
> >
>
> Ok, thanks.
>
> I think that I will use the `mod_wsgi` "namespace", since this same
> interface can be used by other WSGI gateway implementations embeded in a
> web server.

Please don't use 'mod_wsgi', use 'nginx' as you originally said.

There is already going to be enough confusion around you using the
'mod_wsgi' name when the Apache WSGI implementation came first. I
really wish now that I had insisted you specifically call it
'nginx_wsgi' even though you based it on Apache mod_wsgi. To try to be
compatible is one thing, to use the same name in a way that is
confusing is just going to cause more and more problems down the track
if nginx mod_wsgi does get to a point of being usuable.

Whatever you do, please do not go releasing any distinct Python
module/package called 'mod_wsgi' as the Apache mod_wsgi code is all
set up around it being able to do that already, with the assumption
that it has ownership of that namespace because it started using the
name first. I am sure that others will possibly say that I shouldn't
even be using it, but I am just following the tradition set by Apache
in how it names its modules and it seems reasonable that I should be
able to use that same name in Python module/package space much like
mod_python already does. I would hope that Apache mod_wsgi is getting
enough exposure now that it would be accepted that it has reasonable
priority on the name.

If people want to argue the point, then by all means suggest something
else. At the moment, for Apache mod_wsgi 1.X it uses of the name is
internal only and its use mainly symbolic, but in Apache mod_wsgi 2.0
release candidates it does extend outside of the process in as much as
it will attempt to import a Python module/package of that name as a
means of extending Apache mod_wsgi with additional optional
extensions, albeit no such package of extensions has yet been publicly
released. So, it isn't necessarily too late to change it. Note that
'apache' can't be used in place of 'mod_wsgi' for Python
module/package name, as there is already Python code available using
that for SWIG bindings for internal Apache APIs.

Any suggestions on a consensus on how we resolve all this and avoid
arguments down the track are more than welcome. Presuming that is that
people want to object to Apache mod_wsgi assuming that it can use
'mod_wsgi' for the name of a Python module/package. :-)

Graham