Henry Jen wrote:
AFAIK, Windows event logging API supports Event Source and Unix syslog
supports facility and a ident string. So I believe this should be
implemented in a Platform-dependent way instead of being part of the
message for a platform independent approach.
True. Some of this is added in my proposal on the wiki. After some
further looking about on MSDN, however, I've noticed that the Windows
event sources must be individually predefined in the registry. As such,
I've stuck with a set of them that correspond to the Unix syslog
facility constants for the API. I may add a "prefix" option to the
constructors to correspond to the Unix "ident" string.
Sorry for pitching the jxta logging API again. The selector API is for
this purpose so that you can choose what to be logged based on both
facility and level. Which is basically same thing to the selector in
syslog.conf man page.
Given the extremely limited number of facilities, and the fact that I
can't really see more than maybe two being used in a single application,
the value of being able to filter log messages by facility within an
application seems minimal to me. I will happily listen to any arguments
to the contrary, however. For the moment, I've left it out of the
design for simplicity's sake.
Another thing is that, it would be much convenient to allow apr_snprintf
style logging. What I am saying is
apr_status_t apr_log_append(const char *cat, int level, const char *fmt,
...);
Done! I can't believe I overlooked this. In fact, such a function is
so useful that I've decided to see if I can get away with just calling
it apr_log(). ;)
Another API might be useful is to close an log file early. That is,
apr_status_t apr_log_close(apr_log_t *log);
Oops, definitely. It's not on there, but I'll put it in with the next
round of changes; I'm assuming that you'll have a few more points to
bring up shortly.
-Walter
