Phillip J. Eby ha scritto: > At 09:06 PM 12/17/2007 +0100, Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >>> This is precisely why WSGI doesn't really have any "configuration" >>> defined, because the whole idea is that it should be as >>> "plug-and-play" as possible. Server-level configuration options are >>> a liability to be avoided, a sometimes-necessary evil. They aren't a >>> feature. >> >> Disagree. > > Note that your disagreement doesn't retroactively change WSGI's design > goals or rationale,
I disagree with your "Server-level configuration options are a liability to be avoided, a sometimes-necessary evil" phrase. But now I'm not sure of what do you mean by "configuration". > which are what I've been explaining. Your desire > for configuration in one place also doesn't negate others' desires to > simply drop applications into a server with only the most minimal server > configuration possible. > But some applications/middlewares *will* need some configuration; maybe they have safe defaults for configuration parameters, but my problem is: how should these configuration parameters handled? Let's make an example. I want to add a middleware to my application that will send an email when an error occurs. Of course I need to configure some parameters: how do you do this in WSGI? Since the WSGI spec says nothing about configuration, this is up to the user. In mod_wsgi for nginx I have added a `wsgi_middleware` directive, so that it is possible to stack middlewares from nginx configuration (and I think this can be very convenient). Now, the only method for passing configuration parameters to a middleware is to set them in the WSGI environment dictionary, using the `wsgi_var` directive. So, *all* the configuration (nginx server, application, middlewares) can be placed (and, IMHO, should be placed) in the nginx configuration file. I hope that now it is clear what I mean (unfortunalely I'm not very good at explaining things). Manlio Perillo _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
