Subj : MSGID
To   : Jame Clay
From : Maurice Kinal
Date : Thu Feb 10 2005 12:08 pm

Hey Jame!

What do you think about the following idea for MSGID generation?

If the function approaches the last 8 characters in the field as a bit field 
then it has 32 bits to pllay with.  If the last 6 bits (little endian style) 
are reserved for "seconds" - only the first message would actually be seconds 
the rest incremented by one from that base - 6 bits reserved for minutes, 6 
bits for hours, 9 bits for day of the year, that leaves 6 bits for the year 
which yeilds 64 unique states.  That is far more then needed to assure the 
three year uniqueness "standard" of the currently accepted length for that part 
of the MSGID and makes this a far more usable dupe scanning variable.

Another approach could be to reserve the first 3 bits for "year" (a base year) 
and follow the the rest above which could leave a remainder of 3 bits for a 
message number within any generated pkt but then that restricts pkt sizes to 8 
messages per pkt.  I think I prefer the above strategy out of these two 
options.

The beauty of either of these methods is that there is no need to change the 
currently accepted implementation of MSGID and at least this function would 
yeild a better accountable database that could be later employed for dupe 
checking.

Personally I'd like an extra few bytes but that will freak out too many 
programs that are in use out there.

Life is good,
Maurice

--- Msged/LNX 6.1.2
 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1)

.