[Mailman-Developers] From the creation of a ThreadID

[David Jeske]

On Apr 5, 2012 6:42 AM, "Pierre-Yves Chibon" <pingou at pingoured.fr> wrote:
> So I changed to use the Message-ID of the first email of the Thread as
ThreadID.
> Problem is of course, if the admin removes the first email of a thread
> for x or y reasons, then when reloading the archives (for z or a
> reasons), we will loose the ThreadID and actually, the integrity of the
> Thread (each reply to the first email will be split into their own
> thread).
>
> Would anyone have an idea on how to generate a stable and delete/reload
proof ThreadID?

I believe "deletion proof" (i.e. stable thread-ids in the case of arbitrary
deletions) may be provably not possible.

If you really want to be resiliant to arbitrary deletions/reloads, I think
your solution is ultimately going to involve referencing more than one
message in thread URLs..

For example, here is a scheme where 'messages in the thread name the
thread':

1) don't publish thread-ids, but just message-ids... for example, a thread
URL could be allowed to reference the message-id of 'any' message in the
thread.... They could then include more than one message-id, making them
resiliant to a lost messageid later. if some messageid are lost, hopefully
a url someone is holding onto has another messageid that was not lost.

As for how to pick the message-ids, paged display could include a messageid
for a message on the page, in addition to the 'first' messageid of the
thread.

2) create an 'internal only threadid' which you use to correlate messages
together into a thread. (don't show this to anyone) you could generate this
as a GUID, Hash, or the message-id of the message..doesn't matter, since
nobody will see it...

3) when indexing messages, search in both directions
(references/in-reply-to -> messageid, and vice-versa) to find out if the
message belongs in a thread.. if it does, then adopt the 'internal thread
id'.. if you find two different threadids in the two directions, then
rewrite/combine into a single internal-thread-id

-> urls can be somewhat resiliant of deleted/missing messages within a
thread... and completely resilient to changes in other threads
-> threads can be manually edited and merged/split after the fact, with
some level of success
-> could be designed to 'break down' threads that get too big, again with
minimal damage, and some url compatibility