[Web-SIG] serving (potentially large) files through wsgi?

[Graham Dumpleton]

Where does setting up 'logging' module configuration fall in all of
this and who/what should handle it?

I ask as I note that in the documentation for Pylons logging it says:

"""paster, when loading an application via the paster serve, shell or
setup-app commands, calls the logging.fileConfig function on that
specified ini file if it contains a 'loggers' entry.
logging.fileConfig reads the logging configuration from a ConfigParser
file."""

So, the paster serve is doing special setup for Pylons WSGI
components. Without knowing this magic is required, when you take a
Pylons WSGI component to another WSGI server, the logging doesn't work
as expected. To get it to work one has to duplicate the special things
that paster serve is doing in some way.

Graham

On 19/12/2007, Ian Bicking <ianb at colorstudy.com> wrote:
> 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 : ianb at colorstudy.com : http://blog.ianbicking.org
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com
>