William Morgan, 2009-12-31 21:41:
> Out of curiousity, Tero, could the problem also be solved by giving
> the in-reply-to header precedence over the references header?
Well, yes and no. ;)
I think what it needs is to do is
a) consider only the first message in In-reply-to: (like it already
does),
b) prioritize In-reply-to: ahead of References: (like it already
does!) and
c) if In-reply-to: would create a loop or diamond, resolve by
dropping another link ("topmost" conflicting?) and keep the one
from In-reply-to: (currently it drops the link suggested by
In-reply-to: over another potentially coming from (messed up)
References:).
Lemme speculate on this a bit.
Current threading implementation tries to give In-reply-to: precedence
over References: but it still could leave the (in my previous mail
described way) malformed References: affecting the real root of the
thread. By the time we encounter the In-reply-to: headers which would
need to take precedence over the References:, there could already be
bogus parent to the root.
Say we have
First (no In-reply-to: or References:)
+- Second (In-reply-to: First; References: First)
+- Third (In-reply-to: Second, First; no References:)
+- Fourth (In-reply-to: Third; References: Second, First, Third)
If Third is a reply to both Second and First (in that order). Then
Fourth might have References: Second, First, Third. If, when
threading, Fourth is the first processed message then First is seen as
a reply to Second. Now when itself Second is processed, the
In-reply-to: in it would create a loop and is discarded, (see
ThreadSet#link). Resulting in
Second
+- First
+- Third
+- Fourth
which is exactly what the example headers I posted seem to produce
(real root jumps in the middle of one of the branches).
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
