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
