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
_______________________________________________
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
