> From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
> 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 equa
> > 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 CustomL
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 th
> 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 bu
> From: Marc Slemko [mailto:[EMAIL PROTECTED]]
> 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
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
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 defaul
> 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
> probabl
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.
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 th
> 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 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 form
12 matches
Mail list logo
