On 2017 Nov 20 19:49:24, you wrote to me:   
      
    ml>> i'm not aware of a FTN spec concerning RE:... some software may strip   
    ml>> it off on importation into the local message bases... some drop it on   
    ml>> replies... it isn't that critical and software really shouldn't be   
    ml>> linking on subject lines these days anyway... especially considering   
    ml>> how the subject rarely ever gets changed when the topic drifts from   
    ml>> one thing to another... then there are some users that specifically   
    ml>> change the subject so as to try to ensure that their posts are fully   
    ml>> distributed and not caught as dupes by older brain dead software...   
      
    ON> Okay, my counter point to this is some environemnts are not posting   
    ON> the msgid of their reply to as "REPLY". This is where my re-threading   
    ON> code is failing over to "by subject", "by RE:" and "by timestamp" to   
    ON> try to keep the integrity / sanity of the reader.   
      
   make it simple... if it has RE: import it but ignore it during thread   
   linking... but wait... i thought you said you were using SQUish message base?   
   it has several limits that you might want to know of... message time stamps   
   are limited to 2 second imcrements (because of using DOS file time stamp   
   format)... a max of ten messages linked to one... in this age of dupes flying   
   about to try to ensure full distribution of a message, the time stamp may   
   result in false negatives... maybe someone rescanned a message and sent it   
   back out into the network... if it came from a SQUish base, the time stamp   
   will be even and may very well not be the same as the original time stamp...   
   that means that two copies of the message may be identical in every way except   
   the time stamp... at least one BBS package had this problem... when it was   
   discovered and the search ended, that package was fixed... so it is possible   
   that you have some of those messages that you're trying to work with in your   
   archives...   
      
    ON> I have kept the PKTs for the this whole year to help me stress test my   
    ON> tosser and message base classes for performance. And I have noticed   
   certain   
    ON> (keeping the names private for now) systems are posting replies with   
   either   
    ON> NEWMSGID in the REPLY instead of the original (like it was renumbered   
    ON> somewhere along the way to them or durring their system's TOSS phase), and   
    ON> I happen to fail to by subject/re/timestamp and do not find re on the   
    ON> subject - so I fail to "must be a new thread same subject".   
      
    ON> Am I missing something??   
      
   no, you're seeing the schtuff... some of those without REPLY lines are QWK   
   offline mail uploads... QWK doesn't know about FTN control lines so it is   
   possible that the door adds the MSGID but it may not know which message a new   
   post is a reply to so it can't/doesn't created a REPLY line... not much you   
   can do about that... linking on subject is just bad... sorting on time is also   
   bad... you can't really tell if the time in a message is the originator's   
   local time or UTC or what... you can try to figure it out and possibly use the   
   TZUTC control line to help but it is still rough... back when the HMB was all   
   the rage, we decided to not worry about sorting the messages... just toss them   
   as they arrive... it isn't that big a deal anyway... we read from the first   
   unread message to the last in whatever order they arrive...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... Poor Mexico, so far from God and so near the United States - P Diaz   
   ---   
    * Origin:  (1:3634/12.73)