Re: [naviserver-devel] RFE: Expanding ns_log/ns_logctl

[Zoran V. <zv...@ar...>]

Am 25.06.2006 um 14:41 schrieb Stephen Deasey:

>
> Take a look at log4j by the apache project.  This is very popular and
> seems to have inspired a lot of imitators such as log4py, log4c etc.
> Maybe log4c has a better API than the old Ns_ModLog stuff.
>

I did. This is exactly what I thought: they use "kind of" facility
as a hierarchical thing, like some.log.thing which of course
requires you to obtain the logger which knows how to produce
log for some.log-thing and then use that logger to log the entry.
In procedural types of languages we'd need to

   ns_log some-log.thing info "This is the info log"

but this would be backwardly incompatible and would mean total
departure of what we have now.

Consider this stupid little example:

   proc add {a b} {
      if {$a == 0 || $b == 0} {
         ns_log warning "add: one argument is zero"
      }
   }

Whenever/whereever/whoever calls "add" will eventually
produce one warning log line in the common log file.
At the level of the "add" procedure I do not know anything
about log facility for which I'm to emit the log line i.e.
I do not know anything about the calling context.
Hence, this is very simple to use.

If I have 20 threads doing completely separate calculations
and I would like to isolate this log line for just a
bunch of them (i.e. ones within the "some context")
I could do:

   ns_logctl register add_log whatever_id

The add_log procedure must now be clever enough to
"know" what to do for different "whatever_id" arguments.
In the above case, it might somehow obtain the current
value of the ID (whatever that is) in the current thread
and compare it with the passed argument.

So I'm *purposely* building the logic into the callback
and *not* into the server as this will be backward-compatible
for tons of existing code. And, it is much simpler to use
as I do not have to care about the calling context (or facility)
when writing ns_log lines. IOW, I can add the notion of the
"context" from the outside.

The main idea is: as simple as possible, backward-compatible
(no api changes to existing code), ability to route parts of
the global logs to separate log sinks for a "task" which is
potentially executed by number of threads. Every thread should
be able to isolate a "task" by calling some "gettaskid" procedure
which is entirely out of the scope of the log machinery, of course.

I'm sure that we can rewrite the log part to be much more
"fancy" but what we have now (ns_log) serves the purpose
very well and does not require me to think about the calling
context. The only drawback is the lack of finer granularity
as what goes where. I have tried to fill in that hole by
being mininally invasive on the API level.

Now, what do you think?

Cheers
Zoran