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.

Reply via email to