On Apr 5, 2012 6:42 AM, "Pierre-Yves Chibon" <pin...@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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
