Text 47, 57 rader
Skriven 2005-02-09 13:00:08 av mark lewis (1:3634/12)
     Kommentar till text 41 av Maurice Kinal (1:153/401.1)
Ärende: txt2pkt.pl
==================
 ml>> quite simply, use a serial counter just like many *nix
 ml>> mail programs do ;)

 MK> Sounds interesting.  Can (Does) that be generated by the
 MK> variables already onhand needed for header generation?

hunh? what variables? all i'm saying is to maintain a serial counter somewhere
and increment it each time a MSGID is used...

 MK> I'd much rather it be something already there and needed,
 MK> rather then adding an additional scan and/or input from the
 MK> user.  The bottomline is the user ought not to be concerned
 MK> about the creation of any variable other then the message

there is absolutely no reason the user has to have any involvement in the MSGID
creation... none of mine ever have been and neither have i other than creating
MSGID generation routines... of all of them, the serial counter is the easiest,
simplist and one less dangerous than any other... the only danger is if the
counter storage is lost somehow (ie: deleted) and it is restarted at zero or
whatever... this is about the only place that using the system clock for the
initial seed comes into play...

possibly something like using 4hex digits for as much of the julian day number
and reserve the last four hex digits for the serial counter... store the entire
mass in some storage area (ie: a file) and increment the last four until they
hit FFFF at which time you increase the JD portion by one or even calculate a
new JD for the current day and roll the serial counter back to 0000...

no matter what is done, however, if the system clock is used for any portion of
the MSGID, there will always be a danger of generating dupe numbers within the
three year period...

 MK> he/she/it wishes to convert, who it is destined for and who
 MK> he/she/it is.  Also there are only eight characters in the
 MK> field after the space which if hex - the normal operating
 MK> procedure from my observations - only allows 32 bits total.  I
 MK> realize there are a number of approaches that could easily
 MK> deal with this but I'd prefer something that is predictable
 MK> and useable from a server's point of view.  Adding a random
 MK> routine is no real value as it increases operations whereas
 MK> using the time/date makes far more sense and with some thought
 MK> as to processing time would be the best.  If there where a few
 MK> more characters allowed in the second part after the space
 MK> that would have been super.  However, I don't think it would
 MK> be a good idea given the software already in use out there in
 MK> the cold, cruel world.

 MK> Of course simply not adding a MSGID is doable given it isn't a
 MK> requirement.  I am seriously thinking that might be the best
 MK> course of action and damn the consequences, full speed ahead!

too much of that already out there and causing some of the problems which you
are aware of...

)\/(ark

 * Origin: (1:3634/12)