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