MBOX-Line: From MRC at CAC.Washington.EDU  Fri Mar 31 14:37:26 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: <1143843283.3985.18.camel@hurina>
References: <1143819932.8744.163.camel@localhost.localdomain> 
	<Pine.OSX.4.64.0603310950110.26204@pangtzu.panda.com>
	<1143843283.3985.18.camel@hurina>
Message-ID: <Pine.WNT.4.65.0603311421060.4704@Tomobiki-Cho.CAC.Washington.EDU>

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.

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


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

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.

It's certainly possible, but it's not easy.

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

-- Mark --

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

