Subj : message-id
To : andrew clarke
From : Jasen Betts
Date : Wed Nov 06 2002 06:52 pm
Hi andrew.
>> At it simplest This means about 15 lines of C. (or pascal, bssic
>> etc) in each program where they generate the message-ids, and a
>> key file somewhere where all the mail processors can reach it,
ac> Good in theory, but not going to work if you don't have the source
ac> code to everything unfortunately.
yeah, but nothing will fix abandoned closed source software.
ac> I guess the good thing about this is that more and more people are
ac> using open source FTN software, if not most of them, so there may be
ac> hope yet
ac> It could be unreliable if the key file goes missing or gets
ac> corrupted (eg. two programs trying to write to it at once)
yeah, but two programs can't open the file at the same time, that's how
file locking works, in effect the key file is its own semaphone, (unless
there's a network or OS comnfoiguration problem)
in the unlikely event of loss or corruption of the file a simple formula
((unixtime*42) mod 2^32) will give a good starting point since it only
visits the spame part of the serial number range once every three years
ac> but is probably not such a bad solution if you decide not to generate
ac> random numbers. Particularly if the user can decide for themselves
ac> which method to use
That was another idea I toyed with, making the serial number engine
pluggable... where the editor (etc) rouns an external prog to generate the
serial number.
ac> Although I still think a random number generator seeded with the
ac> year + month + day + hour + minute + second + subsecond would do a
ac> pretty reasonable job if the string to be generated was long
ac> enough. I guess I should do some tests
yeah, but no better than just using the year + month + day + hour + minute
+ second + subsecond
ac> In any case Charles Cruden's idea of basically allowing any unique
ac> string seemed the most logical in hindsight. You could then have
ac> a combination of user-supplied-data + random number + MD5 of the
ac> message text, or any other combination you wanted to use..
>> Maybe another kludge could be added to indicate the the msgid so
>> generated is guaranteed to be unique.
ac> May as well invent a new kludge that does both. ;-)
a new kludge won't be compatible with existing software.
^AMSGID is nice on it's own, but ^AREPLY is really useful.
ac>>> Implementations that generate a Message-ID may also optionally
ac>>> generate a MSGID conforming to the FTS-9 standard for systems
ac>>> that do not recognise the Message-ID.
>> is there going to be a replacemnt to the REPLY kludge too ?
ac> Yep.
So converters will be needed for people with old software who want to see
threads, or will both MSGID always be present in messages with with a
message-id
-=> Bye <=-
---
* Origin: Iron Law of Distribution: Them that has, gets. (3:640/531.42)
