Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!atha!aupair.cs.athabascau.ca!lyndon
From: lyndon@cs.athabascau.ca (Lyndon Nerenberg)
Newsgroups: comp.mail.uucp
Subject: Re: V.32 vs. PEP for lots of small uucp transfers
Message-ID: <427@aupair.cs.athabascau.ca>
Date: 14 Nov 90 23:05:13 GMT
References: <6937@sugar.hackercorp.com> <406@aupair.cs.athabascau.ca> <8263@gollum.twg.com>
Organization: Athabasca University
Lines: 35

david@twg.com (David S. Herron) writes:

>The problem is correctly doing outgoing batching ... You really
>want to make sure that there's some number of messages inside the
>UUCP batch file.  In MMDF what I would do is only run the deliver
>daemon infrequently -- and assumably this will usually give me UUCP
>jobs with multiple messages.  But this isn't certain to batch
>multiple messages, and also if the neighbor polls at the wrong time
>then they'll miss picking up messages ..

>So it would be good to push the message into the UUCP queues as
>soon as possible after it arrives.  Which is counter waiting awhile
>so that you can be more sure of having multiple files batched up.

It's easy. You spool the messages in BSMTP format, one per file
without the HELO/QUIT wrappers, using seperate directories for
each site you chat with. Next, create a simple shell script that
can be run to batch and compress all outstanding messages for a
given site and queue it up in UUCP.

For outgoing polls, run the script just prior to the uucico run.

For incoming polls, give the site a login "shell" that:

	1) Kicks off the mail batcher, then
	2) exec's uucico

This requires every site that polls you to have a unique login name
(well, it makes it a lot easier to implement).

-- 
    Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
        {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca

      The only thing open about OSF is their mouth.  --Chuck Musciano