Phillip J. Eby wrote:
Why would they need to? The logging module has its own registry of
loggers.
getLogger('x.y.z') only creates a logger if it doesn't already exist...
You're only shifting the issue from taking loggers as arguments, to
logger *names* as arguments.
Huh? How so? Just
At 02:05 PM 1/15/2008 +, Chris Withers wrote:
Phillip J. Eby wrote:
Why would they need to? The logging module has its own registry of loggers.
getLogger('x.y.z') only creates a logger if it doesn't already exist...
You're only shifting the issue from taking loggers as arguments, to
logger
Phillip J. Eby wrote:
At 02:03 PM 12/21/2007 +, Chris Withers wrote:
I think I'm missing something: what in the logging package makes you
log by which module issued the message?
That's the conventional usage: modules that use logging usually use a
static logger based on module name.
At 05:15 PM 1/14/2008 +, Chris Withers wrote:
Phillip J. Eby wrote:
At 02:03 PM 12/21/2007 +, Chris Withers wrote:
I think I'm missing something: what in the logging package makes
you log by which module issued the message?
That's the conventional usage: modules that use logging usually
On 24/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
On 22/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
[...]
The more and more that this discussion goes on, the conclusion I am
coming to is that WSGI applications should
Robert Brewer ha scritto:
[...]
I still say the answer to should logging be done by the application or
server? is neither. We need a component that covers the everything
else of WSGI; that is, the environment in which servers and
applications are instantiated, connected, started, stopped, and
Graham Dumpleton ha scritto:
On 22/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
[...]
The more and more that this discussion goes on, the conclusion I am
coming to is that WSGI applications should simply not be using the web
server log files for application
Graham Dumpleton ha scritto:
[...]
It therefore seemed more consistent for only wsgi.errors to be bound
to request, given that it comes through request environment. This can
then map to internal Apache ap_log_rerror() function, allowing client
IP to be listed against message in error log
On 22/12/2007, Manlio Perillo [EMAIL PROTECTED] wrote:
Graham Dumpleton ha scritto:
[...]
The more and more that this discussion goes on, the conclusion I am
coming to is that WSGI applications should simply not be using the web
server log files for application logging at all.
The
Graham Dumpleton ha scritto:
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The
specification should then also explicitly say that WSGI applications
should not redirect logging output to wsgi.errors or anywhere else. In
fact, if that was done, there would be no reason to have wsgi.errors
Graham Dumpleton ha scritto:
On 21/12/2007, Chris Withers [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
[...]
In mod_wsgi for nginx I now redirect sys.stderr to server log file (as
suggested by Graham).
I've never really understood this desire to do *anything* with
sys.stderr. Writing to
Brian Smith wrote:
It would make more sense for the WSGI specification to explicitly say
that WSGI gateways are responsible for setting the default logging
output location.
Yes, although by this I assume you mean WSGI gateways are responsible
for allowing configuration of log handlers for the
Graham Dumpleton wrote:
At least in the context of Apache, wsgi.errors is different to
sys.stderr or a global logging module output target. This is because
wsgi.errors is linked to the actual request and so any output can be
correctly redirected to a per virtual host error log.
Yeah, but
Phillip J. Eby wrote:
There are other logging systems out there besides the Python logging
module -- and some of them are better for their specific
purposes.
Can you give some examples?
And the Python logging module doesn't give you any
WSGI-level control over output.
What do you
Manlio Perillo wrote:
Graham Dumpleton ha scritto:
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The specification should then also explicitly say
that WSGI applications should not redirect logging
output to wsgi.errors or anywhere else.
In fact, if that was done, there would be
Phillip J. Eby wrote:
There are other logging systems out there besides the Python
logging module -- and some of them are better for their
specific purposes.
If I was using a framework, I would use that framework's logging
package. But, I specifically want to limit my dependencies as much
Manlio Perillo wrote:
I can modify the code, so that:
- sys.stderr for the main interpreter goes to the main error log
- sys.stderr for subinterpreters goes to the error log declared in the
HTTP location where the WSGI application is mounted
I think that makes sense. To effectively handle
Brian Smith ha scritto:
Manlio Perillo wrote:
[...]
This is the same for Nginx.
sys.stderr is linked to the nginx main cycle logging,
wsgi.errors to the request logging.
In Nginx, there is only one thread, right?
Right.
It is an asynchronous server, with support to multiprocessing.
On 22/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
Graham Dumpleton ha scritto:
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The specification should then also explicitly say
that WSGI applications should not redirect logging
output to wsgi.errors or
On 22/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
I can modify the code, so that:
- sys.stderr for the main interpreter goes to the main error log
- sys.stderr for subinterpreters goes to the error log declared in the
HTTP location where the WSGI application is
Manlio Perillo wrote:
For me, it does feel like the responsibility of the server to
configure logging, and I think this is something that should be
documented somewhere. Afterall, as you guys have been discussing, it's
the server that holds configuration for things like listening sockets,
On 21/12/2007, Chris Withers [EMAIL PROTECTED] wrote:
Manlio Perillo wrote:
For me, it does feel like the responsibility of the server to
configure logging, and I think this is something that should be
documented somewhere. Afterall, as you guys have been discussing, it's
the server that
Graham Dumpleton wrote:
However there are some problems.
The log object has a fixed error level (NGX_LOG_ERR);
this means that every message logged using this object
will have this error level, even if I do, as example:
log.info('just an info message')
I'm missing the
On 21/12/2007, Brian Smith [EMAIL PROTECTED] wrote:
The
specification should then also explicitly say that WSGI applications
should not redirect logging output to wsgi.errors or anywhere else. In
fact, if that was done, there would be no reason to have wsgi.errors in
the first place.
At
Phillip J. Eby ha scritto:
At 11:51 PM 12/18/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 10:10 PM 12/18/2007 +0100, Manlio Perillo wrote:
Ok.
Here I would just say that when someone install something on its
system, it should at least know what he is doing.
And I repeat:
Graham Dumpleton wrote:
Where does setting up 'logging' module configuration fall in all of
this and who/what should handle it?
Indeed, this is definitely something I've wondered myself...
paster, when loading an application via the paster serve, shell or
setup-app commands, calls the
Chris Withers ha scritto:
[...]
For me, it does feel like the responsibility of the server to configure
logging, and I think this is something that should be documented
somewhere. Afterall, as you guys have been discussing, it's the server
that holds configuration for things like
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
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
Phillip J. Eby ha scritto:
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
Phillip J. Eby ha scritto:
At 10:10 PM 12/18/2007 +0100, Manlio Perillo wrote:
Ok.
Here I would just say that when someone install something on its
system, it should at least know what he is doing.
And I repeat: you're welcome to your opinions about what's good or bad,
but that has
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
At 11:51 PM 12/18/2007 +0100, Manlio Perillo wrote:
Phillip J. Eby ha scritto:
At 10:10 PM 12/18/2007 +0100, Manlio Perillo wrote:
Ok.
Here I would just say that when someone install something on its
system, it should at least know what he is doing.
And I repeat: you're welcome to your opinions
Phillip J. Eby wrote:
Range support would be a good example of something
where an option isn't necessary, since properly-written Range
support in the server should be able to tell when the
application has already handled the necessary range-ing of
the output. Thus, having an option to
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
Graham Dumpleton wrote:
Where does setting up 'logging' module configuration fall in all of
this and who/what should handle it?
I'm not sure. What I did with paster serve was expedience, I'm not sure
it's right. I guess paster serve technically also sets up the process,
not just the server
Manlio Perillo wrote:
2) handle the range request in the WSGI application.
Its not hard as long as you do not implement multiple ranges support.
If your object database supports seeks, this should be the most
efficient solution.
This is probably what's wanted. So, if a wsgi app
Chris Withers ha scritto:
Manlio Perillo wrote:
2) handle the range request in the WSGI application.
Its not hard as long as you do not implement multiple ranges support.
If your object database supports seeks, this should be the most
efficient solution.
This is probably what's
Chris Withers wrote:
Robert Brewer wrote:
Apache will interfere, and try to re-apply the range to whatever you
emit. The only solution we've found so far is to tell the app to
ignore
any 'Range' request header when running behind Apache, and just let
Apache have its way. See
Manlio Perillo wrote:
Chris Withers ha scritto:
Manlio Perillo wrote:
2) handle the range request in the WSGI application.
Its not hard as long as you do not implement multiple ranges support.
If your object database supports seeks, this should be the most
efficient solution.
This
Robert Brewer ha scritto:
Chris Withers wrote:
Manlio Perillo wrote:
2) handle the range request in the WSGI application.
Its not hard as long as you do not implement multiple ranges
support.
If your object database supports seeks, this should be the most
efficient solution.
This
Manlio Perillo wrote:
That is, if there is a range request and the application replies 200
OK, you can change that and apply the ranges. But if the application
replies with 206 Partial Content then the range has already been
applied and the server shouldn't do anything to it.
Thanks,
Ian Bicking ha scritto:
[...]
The user shouldn't have to anticipate what an application can or should
do, beyond what the spec says.
I disagree.
The intent of mod_wsgi for nginx, among other things, is to have an
integrated deployment platform for running WSGI applications;
so the
At 07:33 PM 12/17/2007 +0100, Manlio Perillo wrote:
Ian Bicking ha scritto:
[...]
The user shouldn't have to anticipate what an application can or should
do, beyond what the spec says.
I disagree.
The intent of mod_wsgi for nginx, among other things, is to have an
integrated deployment
Phillip J. Eby ha scritto:
At 07:33 PM 12/17/2007 +0100, Manlio Perillo wrote:
[...]
And it's also irrelevant: WSGI applications are composable, which means
that not only does the application deployer not necessarily have any
idea what the application does, the *author* might not know
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
At 12:08 PM 12/10/2007 +, Chris Withers wrote:
Hi All,
What's the best way to serve large files (say detailed images or pdfs)
from a wsgi app?
Is there special support for this?
That's what the iteration part of the protocol is for (well, and a
few other things). If you're not serving
47 matches
Mail list logo
