Subj : MSGID
To   : Jame Clay
From : Maurice Kinal
Date : Tue Feb 15 2005 07:48 am

Hey Jame!

Feb 14 13:35 05, Jame Clay wrote to Maurice Kinal:

 JC>    What do they have over just tracking a number that keeps being 
 JC> incremented? 

Not much other then a base time/date which tells roughly when pkt creation 
occured.  That tells something and could potentially be used to track down 
problems, such as scanning a log file(s) looking for useful information about 
that particular pkt given that most, if not all, log files use time/date to log 
whatever it is they are keeping track of.  A straight incremented number 
doesn't really yeild all that much information about itself other then wrt 
other pkts.


 JC> That it's a function, which can be implemented in more than one 
 JC> place, rather than something like incrementing a number kept in a 
 JC> file... 

It's okay.  There is room for improvement though.

 JC> recently;  kept on coming back to the incrementing serial number kept 
 JC> in a file, for simplicities sake...

I may end up doing just that since some information is going to have to be kept 
onhand for each client anyhow, such as their particular point number, to ensure 
each one gets a unique ID even when the last part of the MSGID is the same as 
another client's.  It could happen and this would help avoid the entire MSGID 
being duped by differing clients.  I have no idea how that might affect other's 
{up,down}stream but there is only so much any one of us can do about this 
"standard" and making it at least half-assed useable.  :-)

 JC>    Haven't had a chance to test it out (have to move again), but will 
 JC> when I
 JC> can.   

No rush here.  I've got some other distractions here as well.

Life is good,
Maurice

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

.