Re: Logs and logs and logs [oh my!]
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 :-)
Logs and logs and logs [oh my!]
I believe Daniel brought this up (or at least he pointed it out to me)
that we go way overboard with logging directives;
* Syntax:
*
*TransferLog fn Logs transfers to fn in standard log format, unless
*a custom format is set with LogFormat
*LogFormat formatSet a log format from TransferLog files
*CustomLog fn format
*Log to file fn with format given by the format
*argument
*
*CookieLog fnFor backwards compatability with old Cookie
*logging module - now deprecated.
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 :)
Bill
RE: Logs and logs and logs [oh my!]
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
Isn't it time to drop TransferLog and CookieLog?
+1
We can accomplish the same by allowing that LogFormat provides the default
for the CustomLog directive, in the absense of an optional [format] arg.
I haven't looked in detail, but I'm guessing that it won't work so easily,
and might just be confusing. I don't see any need to make CustomLog act
like TransferLog. If we are breaking backward compatibility, we might as
well leave only the clearest stuff.
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.
I wouldn't bother with a build-in format. We can just document the
necessary LogFormat directive.
The configuration will be simplest if we just drop TransferLog, CookieLog,
and the one-argument format of LogFormat. No functionality is lost and
everything will be much clearer.
Joshua.
Re: Logs and logs and logs [oh my!]
From: Joshua Slive [EMAIL PROTECTED]
Sent: Sunday, December 30, 2001 11:53 AM
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
Isn't it time to drop TransferLog and CookieLog?
+1
We can accomplish the same by allowing that LogFormat provides the default
for the CustomLog directive, in the absense of an optional [format] arg.
I haven't looked in detail, but I'm guessing that it won't work so easily,
and might just be confusing. I don't see any need to make CustomLog act
like TransferLog. If we are breaking backward compatibility, we might as
well leave only the clearest stuff.
Right now, TransferLog is TAKE1, and CustomLog is TAKE23 ... so there is little
chance this breaks anything. We turn this into TAKE123, and in the TAKE1 case,
we just 'borrow' the last (unnamed / default) LogFormat. I believe it's goodness
to preserve the feature, just not in so many directives.
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.
I wouldn't bother with a build-in format. We can just document the
necessary LogFormat directive.
Fair enough, we might as well just drop this into the list of other, optional
formats that describe older logs in our httpd-std.conf [and friends];
LogFormat %{Cookie}n \%r\ %t cookie
The configuration will be simplest if we just drop TransferLog, CookieLog,
and the one-argument format of LogFormat. No functionality is lost and
everything will be much clearer.
I agree it's simplest, but under my proposal, we lost no functionallity.
If we agree nobody uses the 'default' format TransferLog, then I'm fine with
your suggestion. But I rather guess this is too radical, and some users
probably rely on a globally defined format, that is applied to TransferLogs
in many servers. Anyone have additional thoughts?
Bill
RE: Logs and logs and logs [oh my!]
According to William A. Rowe, Jr.: Isn't it time to drop TransferLog and CookieLog? +1 ciao... -- Lars Eilebrecht - Just give me the coffee... [EMAIL PROTECTED] - and no one will get hurt.
RE: Logs and logs and logs [oh my!]
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] I agree it's simplest, but under my proposal, we lost no functionallity. If we agree nobody uses the 'default' format TransferLog, then I'm fine with your suggestion. But I rather guess this is too radical, and some users probably rely on a globally defined format, that is applied to TransferLogs in many servers. Anyone have additional thoughts? So if someone currently uses LogFormat %h %l %u %t \%r\ %s %b VirtualHost ... Transferlog logs/access_log /VirtualHost etc under your proposal they replace that with LogFormat %h %l %u %t \%r\ %s %b CustomLog logs/access_log and under mine they replace it with LogFormat %h %l %u %t \%r\ %s %b common CustomLog logs/access_log common I don't see how the later choice loses any functionality. The thing that makes Apache configuration complicated is having too many ways to do the same thing. Your change keeps multiple ways of doing the same thing, while my change does not. As a final point (then I swear I'll shut up ;-), take a look at the documentation for LogFormat. I did the most recent rewrite on that, and I still find it almost impossible to understand because of the multiple syntaxes. Now imagine what will happen if you make your change. That documenation will get *even more* complicated, because we will need to make references to CustomLog type x all over the place. The CustomLog documentation will also get more complicated under your proposal. Under my proposal, the LogFormat documentation gets much simpler and the CustomLog documentation stays the same. Joshua.
Re: Logs and logs and logs [oh my!]
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.
Re: Logs and logs and logs [oh my!]
On Sun, 30 Dec 2001, William A. Rowe, Jr. wrote:
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.
I added the %{COOKIE_NAME}C to 2.0 for logging a simple cookie. This
is most likely more useful to most then the CookieLog module.
Cheers,
--
Sander van Zoest [EMAIL PROTECTED]
High Geek http://Sander.vanZoest.com/
