Text 78, 62 rader
Skriven 2005-02-13 12:11:04 av Maurice Kinal (1:153/401.1)
     Kommentar till text 75 av mark lewis (1:3634/12)
Ärende: talking to myself
=========================
Hey mark!

Feb 13 14:10 05, mark lewis wrote to Maurice Kinal:

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

Well then they can safely be ignored and stripped.  Right?  Why waste the bytes
and processing time for absolutely no good reason to man or machine?

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

Yeah.  I thought of that but then reconsidered.  A complete waste of time
seeing it is totally meaningless anyhow, networkingly-speaking.

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

Right.

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

Where is the joy in that?  ;-)

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

Right.  Again we're creating extra variables to the equation.  Personally I'd
like to keep everything restricted to what absolutely HAS to happen and extract
any additional information from variables one MUST have.

 ml> another "problem" is that even with non-duped MSGID serial numbers, 
 ml> it is possible for some software to see a false-dupe...

Right again.  IDs are no assurance of catching true dupes, unique or otherwise.

 ml> because they aren't always looking at the MSGID but only at the 
 ml> header of the message... some of them will go a tad further by 
 ml> looking at the header plus some (maybe 30 or 40) additional bytes to 
 ml> try to see if the message body is different...

How about quoting?  Excessive quoting could potentially cause a false dupe
especially when quotes precede the reply.

 ml> for some reason, i'm also thinking that the message headers that 
 ml> contain seconds are stuck with a 2 second granularity in the same 
 ml> vein that billy's file systems have been from the beginning... 

Could be.  Also what is the "correct" time at any given moment, especially on a
fast machine?

 ml> however, i've not the time nor inclination to go rooting thru the 
 ml> archives to confirm this "memory"...

Heh, heh.  I don't blame you one bit for that.

Life is good,
Maurice

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