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+