Making the Premier Open-Source Fax Management System Even Better
HylaFAX+ includes fixes and features not found in the HylaFAX at hylafax.org. There are various bugfixes and other improvements including improved fax protocol, modem support, and support of some specific modem behaviors. The entire list of changes would be too long to be meaningful to most readers, and such a list is no longer actively maintained, but here is a smaller list of noteworthy differences.
Templating does not necessarily make mail customization any easier. Take for instance the administration of a HylaFAX server that services users of multiple languages. In the minimal-alteration case where mere wordings are being changed, with the traditional approaches the administrator would add a case statement to etc/FaxDictionary and within it set some DICT variables to modify the wordings found in bin/dictionary. With the template approach the administrator would be required to modify wordings in numerous mail templates for each language. In the full-customization case where customized mail content is dynamic and where mail wordings and formatting are being entirely rewritten, with the traditional approaches the mailing scripts are customized, and now the scripts have been simplified to allow that customization to occur within one single mailing function in each script. With the template approach the administrator would be required to learn and probably modify the templating functions within the mailing scripts themselves as well as then recreate all of the numerous template files for each language.
Templating does not make a translator's job any easier. With the "dictionary" approach the translator is merely required to translate a bunch of phrases or words in the bin/dictionary script. With the template approach the translator not only is required to translate but to also then duplicate that work numerous times.
Indeed, it is difficult to imagine a case where the templating approach actually makes customization or translation any easier for the administrator. The only conceivable benefit would be in cases where the administrator needs to make only the most simple alterations and would be prone to cause the mailing scripts to error-out in attempts to modify them without an ability to debug them afterwards.
See the HOWTO's Localization and Customization of E-mails for more a more detailed description of just how easy the HylaFAX+ method of mail customizations really is.
The end-result was that after the creation of HylaFAX+ those developers at hylafax.org took that opportunity to rewrite the batching support at hylafax.org to conform with their design preferences. A number of baseless claims have been made over the years by those developers with respect to the superiority of their work. The truth is that the scheduler (faxq) in current HylaFAX+ releases performs at least as well as the one in hylafax.org releases. Furthermore, there are a number of advantages to the HylaFAX+ scheduler:
The faxstat output could look like this:
CallIDPattern: "NDID=" CallIDLabel: "DID" CallIDDisplay: yes CallIDPattern: "NMBR=" CallIDLabel: "CID" CallIDDisplay: yes CallIDRecord: no CallIDPattern: "NAME=" CallIDLabel: "CID"
And the faxinfo output could look like this:
Modem ttyIAX0 (+1.999.888.0000): Running and idle Modem ttyIAX1 (+1.999.888.0000): Answering the phone, DID:1000, CID:7776665432 Modem ttyIAX2 (+1.999.888.0000): Receiving facsimile, DID:1001, CID:7776664321 Modem ttyIAX3 (+1.999.888.0000): Receiving from "+1.777.666.3210", DID:1002, CID:7776663210
Notice in this last case that "DID" and "CID" are used instaead of CALLID1 and CALLID2, making the information there more meaningful for those using raw faxinfo output and not requiring any translation of those in etc/FaxDictionary for meaningful presentation in the default faxrcvd notification mail.
Sender: +1.777.666.3210 Pages: 2 Quality: Normal Page: North American Letter Received: 2006:10:29 09:00:40 TimeToRecv: 0:17 SignalRate: 9600 bit/s DataFormat: JBIG ErrCorrect: Yes DID: 1002 CID: Lee Howard
Of course, the default behaviors for all of these options is for traditional output in both situations.
For example, on the Eicon Diva Server this configuration item will cause the modem to be initialized with the appropriate origination information provided by the administrator or user in the "FANUMBER" job parameter:
On an IAXmodem this configuration item will cause the modem to be initialized similarly with information provided in the "FAXNUMBER" and "FAXNAME" job parameters:
Similarly HylaFAX+ includes an extension to the ModemDialCmd feature that allows it to utilize a similar capacity in t38modem except that it is done in the dial command like this:
On a t38modem this configuration item will cause the dial command to include the calling number (where %d appears) provided to the server from the job information.
Modem ttyIAX0 (+1.999.888.0000): Running and idle (exempt)
* The chances of JobControl blocking for an amount of time that is at all noticeable is rather slim. And even in the remote chance that the administrator configured a JobControl that would block for a noticeably long time, the chances of that performance hit being a problem are also rather slim. Put those two remote possibilities together and you get something that's really never going to happen in normal, everyday scenarios.
* JobControlWait interferes with batching. Without the block and when using JobControl, it is relatively impossible to guarantee that any jobs will batch properly. And, in fact even an imperceptible delay in processing in JobControl will keep two jobs from batching. In the past HylaFAX users have been very concerned about guaranteeing job batching. Users have never expressed worry about faxq performace difference of the kind that JobControl could normally create.
* Disabling the block on JobControl makes it impossible to someday extend the JobControl RejectNotice to reject job submissions (or otherwise involve JobControl) in the client-server protocol (hfaxd communication).
* To characterize the disabling of JobControlWait as a means to achieve "maximum faxq performance" is only likely to mislead the administrator into doing exactly that.