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. > > But now I'm not sure of what do you mean by "configuration".
I think there might still be some confusion about configuration. I'll offer my take: There's generally two valid kinds of configuration -- the server's configuration (host, port, ssl, etc), and the application configuration (database connection parameters, maybe some theming options, etc). Obviously server configuration goes in Nginx. If you put both of these in Nginx, I think that's fine. That is, if you allow people to create WSGI applications through Nginx, providing information to the application like database connection information, then that's totally fine. There's no standard WSGI way to do that; the only thing approaching a standard for that is Paste Deploy's interfaces (which I'm sure would be possible to support in Nginx -- they are interfaces, not an implementation: http://pythonpaste.org/deploy/#defining-factories). Another kind of "configuration" is configuring the application implementation with respect to its framework. This is where you might choose your template language, or a default charset/encoding. This is where you might choose whether to let the framework handle range requests. This is not actually configuration in my opinion, but it is frequently called configuration. I think it's simply "programming". It has nothing to do with WSGI, and must be fully encapsulated in a WSGI application. People deploying the application should not encounter any of these options. The range stuff apparently is not really an issue of this, as Nginx is acting reasonably and obeying the restrictions of HTTP, which in turn satisfies WSGI. If Nginx was rewriting partial responses to be... doubly partial or something like that, that would really just be a bug. These kinds of bugs exist and are sometimes excused as being "configuration". But when one configuration setting is valid and another is simply invalid, the bug is having that configuration setting at all. But at least this case doesn't seem to be an issue; hopefully other issues that might be similar will be resolved in Nginx. You should never have to have Nginx-specific notes about deploying a WSGI application (except perhaps if you want to provide helpful notes about how to supply the real configuration in an Nginx configuration file). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org _______________________________________________ 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
