[Web-SIG] loggers and wsgi

[Chris Withers]

Manlio Perillo wrote:
> 
> wsgi.errors maybe should have an optional method:
> .msg(level, *args)
> 
> where args is a list of strings
> 
> or
> .msg(*args, **kwargs)
> 
> where the keys in kwargs are implementation defined.

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.

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.

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...)

The only problem here is that the level specified won't necessarilly 
match up to the server's idea of levels, but this is a mapping that can 
either be done intelligently in the server implementation or, worst 
case, by the person putting the components together in the server 
configuration files.

>> Still, there's no problem with a wsgi application doing its own 
>> logging to its own log files, right?
>>
> There is an interoperability problem with external tools like logrotate, 
> since some WSGI implementation are unable to catch signals.

That's why logrotate has copy-truncate ;-)

cheers,

Chris

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