At 09:50 PM 12/18/2007 +0100, Manlio Perillo wrote: >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.
As I said, that doesn't retroactively alter the WSGI rationale. >But now I'm not sure of what do you mean by "configuration". I mean configuring the *server* to correctly run a WSGI application, not the application's configuration. For example, a server option to control whether Range requests are supported would be an example of "server configuration" - i.e., something to be avoided since it forces a user to make a choice about something he or she may know nothing about. >>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? That's not server configuration; that's application configuration. >So, *all* the configuration (nginx server, application, middlewares) >can be placed (and, IMHO, should be placed) in the nginx configuration file. That's application configuration, and isn't related to what I'm talking about. Ideally, a WSGI server will "just run" any application object it is given, without the *server* needing to be configured (except for specifying the object to run). Being able to specify how the application object(s) are created and configured is indeed a nice feature to have in a WSGI server, and that's not what I'm talking about at all. _______________________________________________ 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
