Walter Mundt wrote:
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.
As long as it allows multiple log to be opened and each can have it's
own ident string, I am happy with that. :-)
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.
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. :-)
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.
Not really. :-)
Cheers,
Henry
