On Sunday 07 March 2004 21:35, you wrote: > On Sun, 2004-03-07 at 11:06, Zoran Vasiljevic wrote: > > Oh, misunderstanding... > > Zoran, no I think I understood. From what I understand, each request has > a current url, used by the filter/request proc code to handle requests. > > Your suggestion is to add tcl channel support to ns_log, with a new > command to change this on the fly. > > However, as your example proves, this requires editing all your files > where you want to debug. This is the same issue we have now, logging for > specific areas 1, gets mixed with everything else and 2 requires editing > your files. > > AOLserver has a nice trie structure (generic, but used to store > registered procs and filters). The same structure could be used to > handle logging. A tcl api might look similar to the register_proc api: > > set fd [open ...] > ns_register_logger debug /my/buggy/app/* $fd > ns_register_logger notice /* [open /tmp/server.log a+] > > Maybe too much work for what you want?
Oh, it is not the work that I'm afraid of :) Your idea seems pretty good. The only thing here would be: how to treat non-connection threads? Those are not aware of any URLs. We have usually a dozen of those performing all sorts of non-page-serving tasks. How would you distribute the log info from those threads? Nevertheless, it is a good idea. I will play with this mentally and see if it can be extended to cope with all thread logging. Thanks for the hint. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.