Re: draft-ietf-imapext-thread

[Arnt Gulbrandsen <[e-mail]>]

Mark Crispin <[e-mail]>
> Did you notice that the last argument specifies what messages are to be
> threaded?  So if you only want to thread new messages, you can do:
> 	THREAD REFERENCES UTF-8 NEW

The sound you hear is me kicking myself.

> > The thread=references model specifies an algorithm to be used, in detail,
> > and that algorithm is one that makes several passes over the entire set of
> > messages.  The algorithm is complex, and it's not clear to me whether it
> > can be adapted to be incremental without possibly changing its output, and
> > whether such changes are permitted by the draft.
> 
> That's the problem -- a newly-arrived message can completely change the thread
> tree.  It's therefore quite possible that an "incremental" change (one that
> simply says what is different from the previous tree) is larger in size that
> the previous tree.
> 
> To complicate matters, there is no obvious algorithm for determining how a
> newly arrived message would change the tree; without such an algorithm, you
> have to rethread on the server, and then do a comparison between the old and
> new tree.

I don't think we're talking about the same thing here. You seem to assume
that clients want thread information about the entire mailbox, and that
the question is whether servers can save bandwidth by transmitting changes
to the tree, rather than resending the entire three.  Right?

Well, I am concerned about whether the server can do thread processing at
message delivery time, so that processing a thread request becomes as
cheap as e.g. "fetch flags". I'm concerned about this because I want to do
lots of small thread requests (examples below), and I can't do that if
they're expensive.

> This has been the flaw in the arguments for "subsetting"; you can only
> "subset" in the simplest cases.  It turns out that the only meaningful
> subsetting is on a static tree, which makes subsetting much less valuable than
> its proponents claim.

Actually, subsetting would help with the cases I'm most interested in,
particularly if the server is permitted to also return answers outside the
requested set:  "Show me all the threads where there's new mail", "show me
all the messages from [e-mail], and the threads to which those
messages belong", "show me all discussion in our department-wide archive
where the subject included 'fumble'" and so on.

> > So, if a server does incremental References:-based threading on delivery,
> > can it advertise thread=references?
> 
> I don't know what that means.

Let me try again.

If an IMAP server keeps thread information in the persistent messages
store, and updates that information when a message is written into the
message store, is it possible for that server to comply with the draft's
requirements and advertise thread=references?

I read the draft more carefully last night, and it looks very difficult.
Steps 3-6 have to be done when the client requests thread information, if
I understand it correctly.

--Arnt