Hello Bob!

29 May 03 07:42, Bob Jones wrote to Mike Tripp:

 BJ> I believe there was something else at the time that also drove the 2
 BJ> second decision -- that was out of other fido based sosftware
 BJ> implementations.

You're probably thinking of the 24-char subject-line limit in the 1.0 hash
that was deference to some QWK convention (and Max with internal QWK) that
affected those first 32 bits.  1.10 gave us Longheader, MSGID, and
configurably larger messages to satisfy the Squish hubs that were using
PKTSORT to split large messages down to sizes that Squish could digest. 
PKTSORT was the primary culprit in producing false dupes by violating both
of Scott's original assumptions:  originating unique msgs at less than 2
sec intervals, and if suffixed instead of prefixed with the "1 of
x"," 2 of x", etc, subject line hacks, not necessarily
unique within the first 24 chars considered in the 1.0 hash.

Then the arguments turned to whose MSGID implementations met standards or
were broken, and how... :)

 BJ> I'll agree that we need to change the code that is based on a one
 BJ> or two second rule in the future.  But, I would like to see a
 BJ> "compatible" version of Maximus/Squish running under Linux before
 BJ> we start changing any data structures.  There are some (such as my
 BJ> sself) that will want to transition existing data structures from
 BJ> running systems to a Linux based system.....

Understood.  There are some (such as myself) that would like multiple boxes
with a mix of OSes to be able to access the same instance of the database
simultaneously.  That's also why, if I could only get access to one
enhanced/non-standard binary, a DOS binary would be at the top of the list
instead of the first to go.  :(

.\\ike

--- GoldED 2.50+