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
> > 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,
> > 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
> 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.
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
> by that message-id will continue to function even though the message
> 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
Mailman-Developers mailing list
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9