On 6/25/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 25.06.2006 um 12:48 schrieb Stephen Deasey:
> What happens if you push but don't pop, maybe an uncaught error?
I was also thinking about:
ns_logctl register callback ?arg...?
ns_logctl unregister callback
This way the push/pop is avoided and the problem of non-symetric
usage is gone, as callbacks will be added/removed to/from a list
not a stack.
The callbacks themselves will be called in succession by the underlying
implementation. The very first (default, always present) callback will
be a call to write() as in the current implementation. This guarantees
that log entries will be written into the log file, as today.
Other callbacks may be called in FIFO or LIFO order (there are some
thoughts about that below...)
>
> The very first change in aolserver cvs after being opened was to
> remove the modlog api. Like most logging implementations, it took both
> a facility and a level. Ns_Log only takes a level.
>
> How about adding a 'facility' arg back?
Would that mean ns_log will be something like:
ns_log ?-facility whatever? severity arg ?arg ...?
??
Actually, at the moment I was not thinking about facilities although
it might
be considered as well. My primary motivation behind this is to get
better
*organization* of the existing log information (severity, message,
timestamp
process-id/thread-id).
At the moment we have everything line-wise in one log file. This is
good as
you always know where to look, and there is a time-related order
there as well.
But, disadvantage is: one can easily get lost if you have 100'000 of
lines of
log info generated by different modules all doing logs for the same
"job".
By adding some additional log "sinks" I can channel log information into
appropriate "per-job" log files. This retains the global log file but
adds
more *order* by separating "job-related" logs into corresponding per-
job files.
For example:
proc joblog {level timestamp message jobId} {...}
set id the_job_id_or_handle
ns_logctl register joblog $id
So when somebody says:
ns_log info "This is the info"
the log facility will emit a log line into the log file
(as it does now), but will in addition call:
joblog info 1151234419:0000000 "This is the Info"
the_job_id_or_handle
Depending on the passed user argument(s) (in the above case
the_job_id_or_handle) the "joblog" will know what to do, i.e.
where and how to produce log entry.
The "timestamp" argument will include both seconds and microseconds
(we already have Tcl_Obj type for that).
When the callback is not needed any more, it can be removed
by calling:
ns_logctl unregister joblog
One can have any number of callbacks registered. All of them
will be entered in a list and invoked one after another
with the same level, timestamp and message arguments, but with
different user argument(s).
One additional thing we MAY do is to invent a callback return
value to signalize "continue" or "break" in the similar sense
as filters are doing. This way any callback can forbid lower
level callbacks to be invoked. This is just an idea and it
needs careful thinking though. For example: what does this mean
for the standard logfile sink? If an late callback returns break
would that cut-off the standard log sink or just registered
callbacks? Of course, this will require us to defined order of
invocation i.e. LIFO or FIFO as well...
I hope I managed to convey the *general* idea to you...
Got it.
It might still be a good idea to add 'facility' as a parameter. e.g.
your registering a callback and passing an arg 'id'. Your callback is
distinguishing what to do depending on the arg -- it get's called no
matter what the level is.
If you add facility, you could:
ns_logctl register $facility $priority joblog ?arg ...?
The filtering would be done by the server, rather than the callback.
You're focusing on sinks here, but you need a way to distinguish what
goes where, and facility levels seem like such a standard thing. It
would enable you to turn on verbose logging for just one area of code,
which would reduce log spam.
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.
