Re: [hylafax-users] Efficient mass faxing w. no cover page

["Jay R. Ashworth" <jra@baylink.com>]

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
exist here.

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.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
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 hylafax-users-request@hylafax.org < /dev/null