Walter Mundt wrote:
Henry Jen wrote:
As long as it allows multiple log to be opened and each can have it's
own ident string, I am happy with that. :-)
Okay, I'll add something like this sometime soon unless someone objects.
I guess this depends on which level the apr_log is at.
An application may have several components, and may need to use
several facilities(the concept of facility here is more like the
"ident" part, that's how I define the jxta API) to distinguish those
components. Should they have different logs or a log support multiple
facilities?
If I add log in the apr/apr-util to aid debugging, I may have facility
like thread/queue/ldap etc. But you can argue that this is not what
log is for. :-P
One facility per log works, just a little bit more to be done in the
application. For example, when you want to filter the log, you got
multiple logs to do.
Anyway, that maybe beyond apr's scope for logging. But with those two
features serve really well in the two projects I have been working on.
Would be shame if I need to add another portable logging layer for
this minimum feature set. :-)
I'm not sure really what you mean like this. Please look at the changed
app on the wiki -- when *I* say "facility" what I mean is strictly "Unix
syslog facility"; you seem to mean something different. So there is a
facility "mail", "user", "daemon", etc...and _that is all_. See your
favorite 'man 3 syslog'.
Understand, and you are right, I mean different by facility. So maybe I
should not use the term "facility" to avoid confusion.
The sole purpose is to identify the source, so the "ident" string is
what really matters.
Beyond that, it seems to me that we end up right back in "optimal
cross-platform impl." territory. The exception is that Windows event
sources can be almost-arbitrary strings (they must be regex keys, so no
\ or special chars.)...but see my previous comments on that.
Once again, I am absolutely fine with expanding the scope of the project
to make apr-logging a generally useful logging API. Right now, I see it
more as a portability shim on top of which a full-fledged logging system
might be built outside of APR.
The way I see it is not much different from yours. I see it as a
portable layer for full-fledge logging systems, sort of like apr_dbd for
different databases.
apr-log define a minimum set of logging functionality, the underlying
log system can do things like rotate log files, maintaining extra
logging contexts, etc.
One more consideration: I may add a single win32 specific
'apr_log_win32_set_source' call; applications that want to use
apr-logging AND have their own "source" field in the Windows event
logger could add some conditionally-compiled calls to that function.
That would then disable the use of the syslog-emulation sources for that
log instance.
I wish we can somehow use ident string to register an event source on
the fly in case that is not too much effort. Otherwise, a fixed set of
source and embedded the ident string into the log message is good
enough. Anyway, this is implementation detail to Windows. :-)
The progress so far looks really nice, good work.
Cheers,
Henry
