Text 75, 51 rader
Skriven 2005-02-13 14:10:38 av mark lewis (1:3634/12)
     Kommentar till text 66 av Maurice Kinal (1:261/38.9)
Ärende: talking to myself
=========================
 RT>> A MSGID is a valued item here, especially when it comes to dupe
 RT>> checking, so
 RT>> if you are able to generate them fast enough, then please do so.

 MK> Generating them fast isn't a big issue but making them
 MK> meaningful is a tad tricky given the accepted "standard", if I
 MK> can be so bold as to call it a "standard".

they aren't supposed to be meaningful... they're just a serial number assigned
to a message, for diety's sake...

 MK> If based on time and/or date (is there a difference?) then it
 MK> slows things down and given the current limitation makes it
 MK> even trickier and slower.  That is why I thought a base ID at
 MK> the start and incrementation within a loop for multiple
 MK> messages might be a better objective as it wouldn't add any
 MK> extra calls and is faster then calling localtime for each one,
 MK> which will produce dupes that aren't dupes if limited to
 MK> seconds on a fast machine.  This way it won't matter even if
 MK> the machine is slow enough to produce unique IDs using
 MK> seconds.  This method does speed things up and should produce
 MK> unique IDs for whatever length of years as bits allocated to
 MK> the "year" employed.

you're still looking too deeply... why go thru all that when you can seed a
counter at 0 (zero) and increment until it hits 2147483647 and then roll it and
start over at 0 (zero) again...

based on 365 days in a year, three years is 1095 days... dividing, that gives
us 1961172 messages per day...

surely that's enough and the method easy enough???

the "problem" is storing the serial counter...

another "problem" is that even with non-duped MSGID serial numbers, it is
possible for some software to see a false-dupe... they do this because they
aren't always looking at the MSGID but only at the header of the message...
some of them will go a tad further by looking at the header plus some (maybe 30
or 40) additional bytes to try to see if the message body is different... for
this reason, i place the MSGID immediately after the end of the message header
and all other control lines then follow that...

for some reason, i'm also thinking that the message headers that contain
seconds are stuck with a 2 second granularity in the same vein that billy's
file systems have been from the beginning... however, i've not the time nor
inclination to go rooting thru the archives to confirm this "memory"...

)\/(ark

 * Origin: (1:3634/12)