On Apr 6, 2012 10:49 AM, "Toshio Kuratomi" <a.bad...@gmail.com> wrote: > > 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. > > > This sounds good. So instead of relying on the first message-id of the thread > we internally keep a mapping of all message-ids and stableurl hashes to > either an internal message-id or a tree of messages in the thread.
Advertising
I think of this as keeping a mapping from "rfc822 message-id" to "internal thread-id". I think you are using different words to say the same thing. > When deleting messages, always retain the message-id and stableurl hashes > for that message in the mapping. That way a url that pointed to the thread > by that message-id will continue to function even though the message itself > has been deleted. Perhaps I misunderstood. If you are going to have a record of the deletion (i.e. you can keep a deleted message around in some form), this problem becomes much easier. I thought this desire was to have stable urls and threads when you rebuild and a message is missing. Absolutly if there is a message 'deletion' feature, it should delete the message contents but leave a 'stub' that links the message-id and references/in-reply-to, so it can help hold the thread together during a rebuild. My memory is foggy, but I think we used a technique like this in Yahoo Groups. _______________________________________________ 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
