apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Mundt <em...@spamcop.net>
Subject Re: Google Summer of Code Applications Submitted for apr-build-system and apr-logging
Date Thu, 11 May 2006 10:27:41 GMT
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.


View raw message