Got something to say about this answer?
Hit the question mark to invoke the mailer and
send your comments to the HylaFAQ maintainers.
Why does the logging style in HylaFAX v4.0beta18 has changed?
To: Sam Leffler
Subject: Re: Logging in 4.0b18
Date: Tue, 13 Aug 1996 20:42:50 CDT
From: "Chris D. Halverson"
On Tue, 13 August 1996, Sam Leffler wrote:
> It is trivial to write a script that takes the new logs and merges them
True. That was my first thought, but then I thought I may as well ask
anyway :)
> back into the old-style files. The new scheme has many advantages that
> you may not see. FWIW since beta018 I've added a server log message that
Just curious (and not to be facetious), but what advantages are there?
I'm sure there are, otherwise you would not have put them in, I just
am not seeing them right now.
The old-style log files did not provide a unique way to map a reference to
a phone call back to the session log for the call; it was necessary to know
the exact time of the call and the PID of the faxsend/faxgetty process that
was handling the call. Since the PID was not recorded anywhere it was not
possible to always guarantee a back mapping. The ability to quickly find
out all the information about a particular call is important in a production
environment. I took this idea from the draft T.611 spec that tries to
define something similar to my client-server protocol.
While there currently is no facility for monitoring a session log
directly through the client-server protocol building an ad hoc mechanism
could be done by monitoring the send operation to get the commid (look at
faxwatch for an example of how to do this) and then doing the equivalent
of tail -f on the log file (driven by a changing file size and/or by
listening for send events to trigger reads of the log file). With the
old scheme where all session logs to the same phone number were merged in
a single file doing something like this would be much harder since you'd
need to separate out the log messages for the call you wanted.
There are other benefits to the per-log scheme such as simplifying the
implementation of lots of the shell scripts that do things like return
session logs for failed calls.
I consider the inconvenience of having to search for the specific log file
name to be minor. If there were a way to monitor a job/call through the
client-server protocol then noone would probably care. I've described a
simple scheme for doing this above; maybe someone will even follow through
and implement something. I've even considered adding a new protocol op
to do this basic function as a SITE extension but this won't happen before
the v4.0 release.
Sam
FAQ Index
Q327: RFC for Sam's funky new c/s protocol?