MBOX-Line: From tss at iki.fi  Fri Mar 31 15:17:27 2006
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] Thread extension
In-Reply-To: <Pine.WNT.4.65.0603311421060.4704@Tomobiki-Cho.CAC.Washington.EDU>
References: <1143819932.8744.163.camel@localhost.localdomain>
	<Pine.OSX.4.64.0603310950110.26204@pangtzu.panda.com>
	<1143843283.3985.18.camel@hurina>
	<Pine.WNT.4.65.0603311421060.4704@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <1143847047.3985.42.camel@hurina>

On Fri, 2006-03-31 at 14:37 -0800, Mark Crispin wrote:
> On Sat, 1 Apr 2006, Timo Sirainen wrote:
> > I like being able to see all the new mail at once without having to jump
> > around.
> 
> In that case, you don't want a threaded view.  You want a view that is in 
> message sequence (or UID) order.

Nope, it would still be nice to see the threads. I like pretty much how
OSX's Mail does it, except it uses ordererdsubject-like threading.

> > Aren't most new messages simple insertions? Either a reply to an
> > existing message, or a new message with no message-id references.
> 
> I don't think that's a good assumption, but I haven't done a thorough 
> analysis.

Here's an ugly analyzer script, I think it works correctly:

count=`printf "x select inbox\n"|./imap|grep EXISTS|sed 's/^\* \([0-9]*\) .*/\1/'`
echo "$count messages, threading.."
perl -e 'printf("x delete test\nx create test\n"); for ($i = 1; $i <= $ARGV[0]; $i++) { printf("x select inbox\nx copy $i test\nx select test\nx thread references us-ascii all\n"); }' $count|./imap > log
grep '^\* THREAD ' log|sed 's/^\* THREAD //'|tr -d '\r' > log2
echo "Out of $count new messages, there were this many non-insertions:"
perl -e '$prev = " "; $num = 1; while (<>) { s/[() \n]+/ /g; $new = $_; $new =~ s/$num //; if ($new ne $prev) { print "$new vs $prev\n"; } $prev = $_; $num++; }' < log2|wc -l

With my 787 message INBOX it found one non-insertion and with a 2000
mail mailing list it found 3 non-insertions.

> > If most changes are simple insertions, then I think it should be pretty
> > easy for those cases.
> 
> Not as easy as it sounds.  The server must rethread the entire tree; the 
> message could have been received out of order and thus has pre-existing 
> messages that refer to it.  Then the server must compare the new tree with 
> the old tree.  Only then will it know if it is "just" a simple insertion.

Right. Although I think it's possible to do some optimizations in there
also, eg. if message has no message-id, in-reply-to or references
headers, and there's no existing message with same base subject, it can
always be inserted as a root node.

> Then, a means has to be defined by which the insertion is represented.  Do 
> you do something like message part section numbers?  Or do you send a 
> piece of tree.
> 
> Then it has to be defined how the client does this.  And all of this has 
> to consider the various ways in which a tree can branch and where the 
> insertion takes place.

I think two types of insertions would be enough: "insert as sibling to
message n" and "insert as the first child to message n". Root would
probably be message number 0. So an example reply would be:

* THREAD + 5=S3 6=C5

Meaning message 5 was added as a sibling to 3, and message 6 was added
as 5's first child.

I think that should be easy enough for the clients to handle?

> > And in case something else happens to the threads,
> > it would return everything again.
> 
> Communication links are getting faster all the time.  Against the ever 
> dwindling savings, you have to weigh the costs involved in getting a diff 
> mechanism defined and debugged (this includes getting multiple 
> implementations to interoperate correctly).  We have a difficult time 
> getting multiple implementations of much simpler protocols to 
> interoperate.
> 
> Remember, just because we are technically competant enough to get such a 
> mechanism working does not mean that everybody who implements the protocol 
> will have the same competance.  Past experience has made me quite 
> pessimistic.

Well, I'm still mostly just interested in optimizing this internally in
my server so that the reply gets sent near instantly, but these are
somewhat related goals in that if I can figure out rules how to quickly
update the thread list internally, I can easily send out incremental
updates to clients as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20060401/5dae1623/attachment.sig>
