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.
