Logs and logs and logs [oh my!]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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 format    Set a log format from TransferLog files
 *    CustomLog fn format
 *                        Log to file fn with format given by the format
 *                        argument
 *
 *    CookieLog fn        For 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!]

[Sander van Zoest <sa...@vanZoest.com>]

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                                          sander@vanzoest.com
High Geek                                         http://Sander.vanZoest.com/

RE: Logs and logs and logs [oh my!]

[Lars Eilebrecht <la...@hyperreal.org>]

According to William A. Rowe, Jr.:

>  Isn't it time to drop TransferLog and CookieLog?

+1
  

ciao...
-- 
Lars Eilebrecht                   - Just give me the coffee...
lars@hyperreal.org                 - and no one will get hurt.

RE: Logs and logs and logs [oh my!]

[Joshua Slive <jo...@slive.ca>]

> From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]

> 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!]

["William A. Rowe, Jr." <wr...@covalent.net>]

From: "Joshua Slive" <jo...@slive.ca>
Sent: Sunday, December 30, 2001 11:53 AM


> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> 
> > 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!]

["William A. Rowe, Jr." <wr...@covalent.net>]

From: "Joshua Slive" <jo...@slive.ca>
Sent: Sunday, December 30, 2001 11:53 AM


> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> 
> > 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


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

RE: Logs and logs and logs [oh my!]

[Joshua Slive <jo...@slive.ca>]

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]

> 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!]

[Casey Allen Shobe <cs...@softhome.net>]

I, as a user (I do PHP development), prefer a smaller number of more 
extensible options.

- Casey

On Monday 31 December 2001 09:40 am, Bill Stoddard wrote:
> > 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 :-)

-- 
Casey Allen Shobe
cshobe@softhome.net

RE: Logs and logs and logs [oh my!]

[Joshua Slive <jo...@slive.ca>]

> From: Daniel Lopez [mailto:daniel@rawbyte.com]

> The full functionality is preserved for power users and it is simpler to
> document and use for normal users. It is alittle bit more verbose, but
> that's all.

Right.  I think that is the mistake people are making here.  Verbosity does
not equal complexity.  In fact, it can often be the reverse.

Joshua.

Re: Logs and logs and logs [oh my!]

[Daniel Lopez <da...@rawbyte.com>]

> > 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 problem is not only having TransferLog vs CustomLog, but also with the
many syntax options available that make the whole thing confusing for first
time users.
Below if my initial comment to httpd-docs that started this thread:

"Many of the users, however just want it "to work". They dont want to read
that you can do something three different ways or about some obscure cases.
They just want a step by step guide on what they need to do.

Just take a look at the logging directives for example:

LogFormat allows you to have a logging format and a nickname or
just take a nickname or just take a logging format.
If you have the logging format and hte nickname, then it does not have any
secondary effects. If you have only the nicknmae or the format then it will
set the format for the next TransferLog directive. TransferLog is just a
special case of CustomLog.
Then in turn CustomLog can accept either a format string or a nickname.

This allows you much more flexibility but it obscures how to just log stuff
to a file, which is what most people want. It will be much more easier if:

LogFormat only takes two arguments, format and nickname
CustomLog only takes a nickname argument, previously defined on a LogFormat
TransferLog is removed, since is a subset of CustomLog."

The full functionality is preserved for power users and it is simpler to
document and use for normal users. It is alittle bit more verbose, but
that's all.
I would also rename CustomLog to REquestLog or simply Log, but that is
secondary

Daniel

Re: Logs and logs and logs [oh my!]

[Bill Stoddard <bi...@wstoddard.com>]

> 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 :-)

RE: Logs and logs and logs [oh my!]

[Joshua Slive <jo...@slive.ca>]

> From: Marc Slemko [mailto:marcs@znep.com]

> 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.

[Didn't I say I was going to shut-up?  Oh well.]

I disagree with you in this case.  It is easiest to configure something when
all the buttons and knobs are in the same place, not when they are scattered
all over.  Let me give a couple specific examples/arguments:

1. Your argument only makes sense if we are going to encourage most people
to use TransferLog and keep CustomLog for the users with "advanced" needs.
But we don't even include TransferLog in httpd.conf-dist. The only people
using TransferLog are people who started using Apache a long time ago, or
people confused by the documentation (see next entry).

2. Having more than one way to do things makes the documentation much more
complicated.  A specific example: The logrotate documentation has always
used TransferLog for its example.  One of the most common questions I hear
about logrotate is "I want to use logrotate, but I want to exclude .gifs
from my logs; what do I do?"  They don't understand that the example also
applies to CustomLog.  To have clear documentation, we have been changing
most things to refer to CustomLog, since it subsumes the TransferLog
functionality.  But then, again, this defeats the purpose of having a
"simple" directive that most people use.  Refering to both directives
everywhere would be even more confusing.

3. Users who just want the simplest stuff are probably just going to use the
default httpd.conf and forget about it.  What we care about is people who
need to make changes from the defaults.  If TransferLog is in the default
httpd.conf, then any change other than the filename requires learning a new
directive and its relationship to the old directive. With CustomLog, you
simply expand on what you already have.  The link between the log file and
the log format are much clearer with CustomLog (even if you use a named
format) and it is easier to learn to do complex things like conditional
logging.

As far as the name "CustomLog", I don't think it is that bad.  It is a
"customized logfile".  The fact that there is no such thing as a
non-customized logfile doesn't really hurt understanding of the concept.

Joshua.

Re: Logs and logs and logs [oh my!]

[Marc Slemko <ma...@znep.com>]

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.