[ Brian L. Heess writes: ]
>
> On Mon, 26 Jan 1998, John Van Essen wrote:
>
> > Well - I don't see the need for having a timezone in there at all,
> > since this is the time that majordomo made the entry in the log and
> > will always be using the local machine's timezone.
> >
> > What would you do with this TZ info, anyway?
> >
> > I think it's easier to always leave it out to avoid having to skip it
> > when parsing the logfile. :)
>
> Well, I put it in there because web servers do... :) It seems to be part
> of the CLF thingy. Actually, I wonder if there is a spec beside the
> server code (ie: Apache, NCSA, etc.).
>
> marie.thru.net - - [28/Jan/1997:14:37:17 -0500] "GET / HTTP/1.0" 200 449
Without the TZ it's ambiguous. Think DST. Think network (WAN). The
+/-hhmm form is much preferable to TZ names, BTW.
CLF is far from ideal, but it does have the advantage of being somewhat
of a standard, albeit ad hoc. I just hope that no one is expecting log
format changes to be part of any 1.xx release. I classify it as a new
feature. With any luck, logging, and formats thereof, will be a module
in Mj 2, perhaps even with several interchangeable modules to choose
from. CLF is nice *if* existing log scanners can make use of it (I fear
that the fields are too different), but just adopting the concept of
fixed fields with placeholders is worthwhile.
The keyword/value idea has a lot of merit, too, and is what I'd like to
see implemented in Mj 2, along with the concept of level or types of log
messages, i.e. informational, warning, error, abort, debugging, etc.
I suppose these could be ranges, a la HTTP response codes and various
others, but scales of 1 to 10 leave me cold. Although quite extensible,
some rules would be needed establishing required fields and/or defaults
for unspecified fields, e.g.:
{type info} {time 28/Jan/1997:14:37:17 -0500} {list foo_list} {request
subscribe lou_user@where.net} {requestor luser@some.where.net}
{status confirmation requested}
Maybe if no "type" field appeared, it's assumed to be an "info" entry.
A "time" field would always be required, but other fields would be
context dependent, with some sort of hierarchy dictating which fields
establish the context. This would make it pretty easy do report "all
error and abort entries", "all entries subscribing to list foo_list",
"all unfulfilled subscribe confirmations to foo_list", etc.
Sorry, that kinda got off subject, but I thought it worth mentioning.
--
Dave Wolfe
Follow-Ups:
References:
|
|
