From dev-return-16329-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu May 11 17:49:50 2006
Return-Path:
Delivered-To: apmail-apr-dev-archive@www.apache.org
Received: (qmail 33065 invoked from network); 11 May 2006 17:49:49 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 11 May 2006 17:49:49 -0000
Received: (qmail 85436 invoked by uid 500); 11 May 2006 17:49:47 -0000
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 85306 invoked by uid 500); 11 May 2006 17:49:46 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post:
List-Help:
List-Unsubscribe:
List-Id:
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 85258 invoked by uid 99); 11 May 2006 17:49:46 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 May 2006 10:49:46 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of slowhog@gmail.com designates 64.233.184.227 as permitted sender)
Received: from [64.233.184.227] (HELO wr-out-0506.google.com) (64.233.184.227)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 May 2006 10:49:45 -0700
Received: by wr-out-0506.google.com with SMTP id i11so417018wra
for ; Thu, 11 May 2006 10:49:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
b=nsLXJoGpCmYzIvYk2pcXdk3+gb63DlGFloIKf/59RWLVH+hMm/+EVmFGAyimXXD8cms4UILycEtu28dVjxQTjnqq0sZIDrceAqIwGrp5FNR3h0dVKRJgut7KpbqLyRn8lXFI9YHg5aGIbKtDvdel/MtUH2PN60EN6IE8B6WirQ8=
Received: by 10.54.96.7 with SMTP id t7mr1118504wrb;
Thu, 11 May 2006 10:49:23 -0700 (PDT)
Received: from ?192.18.191.139? ( [192.18.191.139])
by mx.gmail.com with ESMTP id 39sm1253760wrl.2006.05.11.10.49.22;
Thu, 11 May 2006 10:49:23 -0700 (PDT)
Message-ID: <44637910.6020906@ztune.net>
Date: Thu, 11 May 2006 10:49:04 -0700
From: Henry Jen
User-Agent: Mail/News 1.5 (X11/20060315)
MIME-Version: 1.0
To: Walter Mundt
CC: dev@apr.apache.org
Subject: Re: Google Summer of Code Applications Submitted for apr-build-system
and apr-logging
References: <445FE273.4060202@spamcop.net> <445FF22B.1090305@ztune.net> <445FF8AA.7050800@spamcop.net> <4460087C.2080102@ztune.net> <4462BA16.5010600@spamcop.net> <4462F80F.2090108@ztune.net> <4463119D.9080107@spamcop.net>
In-Reply-To: <4463119D.9080107@spamcop.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Henry Jen
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
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.
Cheers,
Henry