[Web-SIG] loggers and wsgi

[Chris Withers]

Manlio Perillo wrote:
>> I don't really see how this helps. If it's optional, then ever wsgi 
>> app will need a bunch of if/then/else to decide if this method can be 
>> called and what to do instead.
>>
> This is not a problem. The job can be done by a middleware.

...which everyone will then have to use...

> My idea is to add a message like interface to wsgi.input, in addition to 
> the stream interface.

That does sound like a plan, although I'd prefer *just* the message like 
interface, and the more it smells like the standard python logging 
framework the better.

>> Likewise, having implementation defined parameters means the 
>> application developer has to tie the app to a list of compatible 
>> servers and cater for each one.
>>
> Again, not a real problem, IMHO.
> This is the only solution for better support several environments.

I'll respectfully disagree with you there ;-)

>> Surely a much better idea would be to give wsgi.errors a logger 
>> attribute which behaved like a standard python logger?
>> (or, in fact, just make wsgi.error a python logger object...)
> 
> No, I think this is wrong.

Why?
(the important point is that it behaves like a python logger object, not 
too fussed about how it's implemented...)

>> That's why logrotate has copy-truncate ;-)
> 
> This is only a work around.
> I think that, where possible, WSGI must allow better integration with 
> the "server environment".

Again, I'll respectfully disagree with you there on both counts...

> By the way, there is still the problem with a stream/message object not 
> bound to a single request; this is required by applications that needs 
> to log, as an example, a database connection pool.

Not sure what you mean...

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk