MBOX-Line: From MRC at CAC.Washington.EDU  Fri Mar 31 15:30:03 2006
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] Thread extension
In-Reply-To: <1143847047.3985.42.camel@hurina>
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>
	<1143847047.3985.42.camel@hurina>
Message-ID: <Pine.WNT.4.65.0603311522280.4704@Tomobiki-Cho.CAC.Washington.EDU>

On Sat, 1 Apr 2006, Timo Sirainen wrote:
> I think two types of insertions would be enough: "insert as sibling to
> message n" and "insert as the first child to message n".

You need to define the semantics when UID THREAD is used.  Also, you need 
to define what happens if the new message has children (insertion as 
opposed to append).

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

You'd be surprised at what people find to be "not easy".

> 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.

I don't understand.  A thread should be nearly instantaneous, even for a 
very large mailbox, if you use a hash table.  It's probably also a good 
idea to cache the data needed to thread so it's available the next time 
you thread.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

