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.