Message-Id: <3.0.3.32.19970825144342.0095a360@localhost>
Date: Mon, 25 Aug 1997 14:43:42 -0700
To: new-httpd@apache.org
From: Brian Behlendorf <brian@organic.com>
Subject: Re: Keep it simple
In-Reply-To: <97081923323484@decus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

At 11:32 PM 8/19/97 -0400, Rodent of Unusual Size wrote:
>    Brian, an I/O is an I/O, and I don't see how it is ever less
>    expensive than spinning some CPU and manipulating memory - which is
>    what doing it in the server rather than in a piped log means.  

I don't doubt that doing it in the server will be more efficient, though
I'd be surprised if it as a non-negligible part of the total resource load.
 The point in /not/ putting things like this in the core code is to manage
complexity.
 
>    Also,
>    we're going multiplatform, so what sort of broadbase support is
>    there going to be for an external script provided by us?  (Not an
>    objection, but a serious query.)

Doesn't even have to be a perl script; it could be a C program using the
same C code you were planning on using in mod_log_config, etc.  It could be
built as another target under /src/support.  

>    I still strongly think that the log/don't-log decision has a place
>    in the server.  Log content manipulation certainly shouldn't be
>    there, but look at logging in general: most logging systems allow
>    you to tailor what/how much gets logged (syslog, named, auditing,
>    accounting systems, ...).  Why should Apache spit voluminous output
>    that the user has to weed if all he wants is a simply-defined subset?
>    Sure, a script can do it - but I ask again why it should have to?
>    One of the objections to removing mod_log_referer from the
>    distribution is that it provides [limited] conditional logging that
>    my first-pass replacement didn't maintain..

I could be talked into this... could all the cases you wish to support be
handled by a simple "LogNot" directive, which was per-vhost, per-dir,
per-files and per-location configurable?  Or perhaps mod_log_config looks
for an env variable, settable via SetEnv or SetEnvIf?  A /clean/ way to
mark a request non-loggable would be fine.  I'd still argue anything more
fancy should be shoved down a pipe to a process, or even handled
out-of-band using USR1 rotation.

>    Of course some of this is not liking having my ox gored, but most of
>    it is serious objective consideration of what I think is the Right
>    Thing.
>
>    So I propose this to a vote:
>
>     1. Enhance LogFormat to work as either of
>    	 LogFormat fmtname "format-string"
>    	   or
>         LogFormat "format-string"-or-format-name
>
>     2. Enhance CustomLog to
>         CustomLog "format-string"-or-format-name
>    	   or
>    	 CustomLog "format-string"-or-format-name env=[!]varname
>    	(allows extension to other conditions besides envariables)
>
>    Examples:
>
>     CustomLog CLF logs/access_log
>     LogFormat Referer "%{Referer}e -> %U"
>     CustomLog Referer logs/referer_log env=LOG_REQUEST
>
>    Please note that I've decided to give in to Dean's and Randy's
>    objections to an additional directive.  Do I hear three +1s willing
>    to meet me half-way? <g> (And no -1 from Brian?)

I really don't like either of the above.  I feel like such a weenie -1'ing
them, though, if they enjoy popular support from others.

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL           brian@organic.com - hyperreal.org - apache.org