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, t
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
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
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
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
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 fil
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, st
Graham Dumpleton wrote:
> On 22/12/2007, Brian Smith <[EMAIL PROTECTED]> wrote:
> > Manlio Perillo wrote:
> > > Instead of using sys.stderr, a better solution is to add a new log
> > > object to the WSGI environment dictionary, so that each
> > > application can have its error log redirected to dif
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 al
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
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 problem with this is that log files cannot be easily rota
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 app
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
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 h
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 multiprocess
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:
> 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,
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. Take a look at the distutil
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 yo
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
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 t
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 w
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.stder
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.
A
At 07:44 AM 12/21/2007 +0700, Brian Smith wrote:
>In
>fact, if that was done, there would be no reason to have wsgi.errors in
>the first place.
There are other logging systems out there besides the Python logging
module -- and some of them are better for their specific
purposes. And the Python
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 miss
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
> >> th
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 soc
At 12:12 PM 12/19/2007 +0100, Manlio Perillo wrote:
>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
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 li
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
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 doin
On 19/12/2007, Ian Bicking <[EMAIL PROTECTED]> wrote:
> 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.
Problem is it h
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
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 func
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 t
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 yo
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 pos
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
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 nothing to do with WSGI's design rati
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
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 a
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 configur
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 b
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 kno
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
>"integrate
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
Manlio Perillo ha scritto:
> [...]
>
>> You should be able to detect whether interference is allowed based on
>> the response status, shouldn't you?
>
> Right.
>
>> That is, if there is a range
>> request and the application replies 200 OK, you can change that and
>> apply the ranges. But if
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.
>>
>
At 04:44 PM 12/17/2007 +, 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
Ian Bicking ha scritto:
> 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, t
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
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
>>>efficien
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 htt
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 http://www.cherrypy.org/changeset/13
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 is pro
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 proba
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 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?
>
> Also, does wsgi offer anything to help with http range requests and the
> like?
It's not part of any WSGI standard, but in We
Chris Withers ha scritto:
> Manlio Perillo wrote:
>>
>> Note however that this is an optional feature, so a wsgi gateway is
>> not required to implement it.
>
> What happens if the app is expecting the gateway to support it and the
> gateway does not?
>
You can still use something like:
class
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 servin
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?
Also, does wsgi offer anything to help with http range requests and the
like?
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
62 matches
Mail list logo
