Subj : Compression question
To   : Bo Simonsen
From : Mike Tripp
Date : Fri Jul 11 2003 12:42 pm

Hello Bo!

10 Jul 03 17:33, Bo Simonsen wrote to Bob Jones:

 BJ>> The problem is that such normal packets get reprocessed by later
 BJ>> lines in the route.cfg file. So, if you have a line that is like
 BJ>> 'ROUTE CRASH 1:10/3 1:ALL 2:ALL 3:ALL 4:ALL 5:ALL 6:ALL', what
 BJ>> was in a normal flavored packet for a given node now gets packed
 BJ>> for 1:10/3.

 BS> Okey! It doesn't use TOPDOWN properly.

Be sure and tack in an IMHO for that... :)

Squish can do tossing, scanning, packing, and routing combined in each and 
every run.  That means that the length of each run may vary dramatically.  The 
"never touched more than once" approach means maintaining a static snapshot of 
the "before" outbound for the duration of the run while files are renamed as a 
result of routing statements and their associated pointer entries are 
removed/created in multiple ?LOs.

Scott's approach requires reinterpretation of the outbound's state at each step 
in ROUTE.CFG instead of at the beginning of the run only.  It is synonymous 
with wildcard processing of filenames in a BAT/CMD file, which =IMHO= is a 
better example of "proper" top-down than any specific approach of any specific 
tosser. :)  While I'm not prepared to install/extensively test to confirm my 
suspicions, I suspect that the Confmail approach would also be more susceptible 
to concurrency issues then the Squish approach with multiple LAN nodes 
manipulating outbound at the same time.  At minimum it means that Squish may 
get work done in the same run that wouldn't get done until a subsequent run 
with the Confmail approach.

..\\ike

--- GoldED 2.50+
 * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)

.