HylaFAX The world's
most advanced open source fax server
Re: [hylafax-users] Efficient mass faxing w. no cover page
On Thu, Jan 10, 2002 at 04:50:49PM -0500, Daniel Dumitriu wrote:
> This has cooled me down a bit. I understand how this might not be very
> important for most people. After all, we don't, generally, fax thousands
> of people each day. Except for some businesses that actually rely on this.
> Unfortunately, I will have to leave things the way they are, and have a
> separate copy of the document queued for each destination.
> My problem with this is not the disk space being wasted. The problem is
> that the clients take forever to spool a the same document to thousands
> of destinations. I was looking into ways to trim that waiting time down
> a bit.
> As for outsourcing the development of a custom client, I'm afraid that
> it is not an option, at least not at this point.
Well, you don't need to create an entire custom client.
The issue here is that the command line hasn't the space for as many -d
options as you need. The -d option calls a routing in sendfax(1HF)
which adds a destination to the list.
At some time in the past, on one of the mailing lists, the idea was
discussed of adding a new option, -L for example, that accepted the
name of a text file containing a set of destination strings
("UserName@faxnumber"), one per line.
You could then generate your dialling list, and say
sendfax -L mynumbers blah.ps
and they could all go out on one render.
I'm not the coder for this, but someone who *knew* C++ could likely
make the necessary modifications in, oh, about an hour. Such people
If you were willing to chip one of them a bill or so, you might find a
taker, particularly if you were willing to release their changes back
to the sources.
> Since my system must serve a few people that submit a relatively small
> number of documents from their Windows workstations to be transmitted to
> thousands of numbers grouped in three or four "phone books",
> my solution is going to be something along the following ideas:
> - define a "virtual" printer associated with each "phone book". Each
> such printer will consist of an interface script that cycles through the
> destinations in the phone book and spools the faxes.
> - export/share the printers using Samba
Given what you need to do, yeah, that sounds like a workable
architecture. The patch I proposed above would still make it much
faster and more disk-efficient.
Jay R. Ashworth firstname.lastname@example.org
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?"
-- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
____________________ HylaFAX(tm) Users Mailing List _______________________
To unsub: mail -s unsubscribe email@example.com < /dev/null