Chris Withers ha scritto: > 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. >
This is not a problem. The job can be done by a middleware. My idea is to add a message like interface to wsgi.input, in addition to the stream interface. > 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. > 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. This can be done, of course, by a middleware. > 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 ;-) > This is only a work around. I think that, where possible, WSGI must allow better integration with the "server environment". 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. > cheers, > > Chris > Manlio Perillo _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
