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'.
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.
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.
-Walter
