apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Jen <henry...@ztune.net>
Subject Re: Google Summer of Code Applications Submitted for apr-build-system and apr-logging
Date Thu, 11 May 2006 08:38:39 GMT
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

Mime
View raw message