Hopefully for NetWare this will be an Apache 1.3 issue only. It is
a long story, but Apache 1.3 was built on our old CLib libraries which
do not support functionality like pipes. Apache 2.0 and beyond is based
on LibC which is a ground up rewrite of the standard library
functionality and brings us much closer to the rest of the world. With
LibC, pipes as well as some other issues that we have had, should no
longer be a problem. You are right, we still don't have child
processes, but for the most part I have been able to fake it with
threads. Our current plans for Apache 2.0 are to support the RotateLog
utility just like everybody else. But we needed something to patch this
hole in our 1.3 story. I will go ahead and check in a mod_log_nw module
and switch our build to use that instead.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., a leading provider of Net business solutions
http://www.novell.com
>>> [EMAIL PROTECTED] Wednesday, February 27, 2002 4:11:00 PM >>>
At 04:56 PM 2/27/2002, you wrote:
>Isn't that the whole cross platform point here? If another platform
>decided that it was better for them to have log rotation in Apache,
>isn't it better to share code rather than reinvent or duplicate the
>wheel? I don't have a problem with separating the code into another
>module, but I would rather share than duplicate.
For Apache 2.1 I agree with dirk's general sentiments; break up
logging
into several layers, each of which can be changed for appropriate
purposes,
and the uberlayer could either create one logging file, or handle log
rotation.
It is probably more efficient as a thread of the server than a seperate
app,
even in a model like worker, on at least some Unix platforms.
But the answer has been [continues to be] that mod_log_config
configures
what goes into a log, and allows piped logs for extensibility.
Proposals
to change this are vetoed about four times a year.
Consider this, today you want name format foo. Tommorow someone wants
to introduce format bar. Now someone comes along and wants to roll in
the
logresolve style logic. Next we decide we want additional log
filtering.
The existing schema allows for extensibility via pipes/log children.
What is
brought up frequently is rescoping the logging in 2.1 to be more
modular, so
that these sort of things -could- fit into the server without
crowbars.
But think about one of two tacts. One - mod_log_netware probably
makes
the most sense for 1.3 - it impacts no other code. Also consider this
for 2.0
and beyond - if the user could drop in a pipe you would be fine. But
there are
no pipes and child processes, correct? Look at creating an alternative
schema
for Netware that allows you to create faux-CGI type applications, such
as log
children or cgi apps. That would be far more useful going forward than
hacking
more cruft into mod_log_config.
