Re: [sup-devel] [PATCH] XapianIndex.each_message_in_thread_for yields messages in cronological order

From: Rich Lane <rlane@club.cc.cmu.edu>
To: William Morgan <wmorgan-sup@masanjin.net>
Cc: sup-devel <sup-devel@rubyforge.org>
Subject: Re: [sup-devel] [PATCH] XapianIndex.each_message_in_thread_for yields messages in cronological order
Date: Wed, 30 Dec 2009 12:01:37 -0500	[thread overview]
Message-ID: <1262190807-sup-434@zyrg.net> (raw)
In-Reply-To: <1262182085-sup-1405@masanjin.net>

Excerpts from William Morgan's message of Wed Dec 30 09:10:54 -0500 2009:
> Reformatted excerpts from Tero Tilus's message of 2009-12-29:
> > For what I know you might trigger this by replying to many messages at
> > once and thus having a list of ids in-reply-to header (in whatever
> > order of course, rfc doesn't require any particular order) instead of
> > one.  Then when you reply to this message using MUA that is bold
> > enough to try to form References: with the standard in-reply-to +
> > my-id method even if RFC 2822 says "trying to form a References: field
> > for a reply that has multiple parents is discouraged and how to do so
> > is not defined in this document".  You end up having References: which
> > has bunch of (thread-wise) random ids in random order instead of the
> > rfc-specified original, reply, replytoreply, etc. chain of ids.
> 
> It's worth reading the top bit of http://www.jwz.org/doc/threading.html
> for what In-reply-to: and References: look like in practice. (Basically:
> a mess, and the references: header in particular can be truncated in any
> way that any MUA feels is reasonable.)
> 
> The threading used by the Ferret indexer is a pretty faithful
> reproduction of the algorithm described on that page. I'm not that
> familiar with the one used by the Xapian index, but a cursory
> examination suggests it's a little more fragile.

I'm assuming you're talking about each_message_in_thread_for, since
that's the only Index method that deals with threading.

In what order does ThreadSet#add_message expect to get messages in?
This determines the order from Index#each_message_in_thread_for. I'd
assumed an arbitrary ordering would work because add_message needs to
handle this case anyway to work with messages arriving out of order from
the source (which happens all the time) and then added to the Inbox
threadset. AFAICT JWZ's algorithm should work regardless of the order
messages handed to it.
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel