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 17:49:04 GMT
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.


View raw message