> 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.
>
I agree with Marc.
Bill (who has no time for a more lengthly response :-)
