On Sun, 30 Dec 2001, William A. Rowe, Jr. wrote:

> Isn't it time to drop TransferLog and CookieLog?
> 
> We can accomplish the same by allowing that LogFormat provides the default
> for the CustomLog directive, in the absense of an optional [format] arg.
> 
> And if we offer a built-in (or default-config'ed) 'cookie' format, 
> of "%{Cookie}n \"%r\" %t", then it's a two bit change to turn a CookieLog
> into a CustomLog file cookie command.
> 
> One of the major 'bugs' in Apache is it's configurability ... I don't think
> we want to perpetuate the many-directives-to-accomplish-the-same-thing
> methods.  Folks are making minor changes already to their configs, this is
> as good a time as any to jettison some of the extra cruft :)

I'm not convinced it is any simpler to have one directive with a
whole bunch of options as opposed to a simple version of a directive,
which does what most people want, and then another one that lets them
do the complex stuff.

The complexity of configuration isn't defined by the number of
directives.  I think that requiring people to specify more options
to perform the "simple case" of configuration contributes to people being
intimidated by Apache's flexibility even when they don't want to use that
flexibility.  The ability to use a custom logging format shouldn't 
require that every user understand that ability just to use the "default"
format that most people use.

Regardless, the name "CustomLog" just seems completely wrong for
the default format, and if directives are changing around then adding
another legacy ("well, it is called customlog because there used to be
another one and...") doesn't make sense.

I would recommend either having what we have now, with a simple
directive (eg. TransferLog) and a more complex one (eg. CustomLog), or
having a simple form of the directive (eg. "TransferLog filename")
and a more complex form (eg. "Transferlog filename format").  People
shouldn't have to specify a format for the simple case.  

While it is simpler to do away with special cases from the code's
perspective, that isn't the user's perspective.

Reply via email to