mailing list archives

Is anything happening to draft-gulbrandsen-imap-inthread? I'm probably
going to be implementing something like it in a few months.

I'd like to make it slightly simpler though. I think it would be enough
if it worked only with THREAD command, and only using the same thread
algorithm as selected for THREAD.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080131/29484eea/attachment.sig>

Timo Sirainen writes:
> Is anything happening to draft-gulbrandsen-imap-inthread? I'm probably 
> going to be implementing something like it in a few months.

I let it lie. Started work on that again only last December, and I now 
plan to finish my implementation first.

> I'd like to make it slightly simpler though. I think it would be 
> enough if it worked only with THREAD command, and only using the same 
> thread algorithm as selected for THREAD.

Elaborate, please?

Arnt

On Jan 31, 2008, at 10:25 PM, Arnt Gulbrandsen wrote:

>> I'd like to make it slightly simpler though. I think it would be  
>> enough if it worked only with THREAD command, and only using the  
>> same thread algorithm as selected for THREAD.
>
> Elaborate, please?

The main use I see for INTHREAD is to let client display a list of  
threads where a search condition matches. This would be done with  
THREAD algorithm .. INTHREAD same-algorithm .. command. And since they  
use the same algorithms, it's most likely possible to optimize for  
that (I haven't thought of how yet). But if the INTHREAD needs to work  
with different algorithm than THREAD or if SEARCH INTHREAD is allowed,  
it can't use the THREAD's optimized code path, requiring an  
alternative nonoptimized code path which will be rarely (if ever) used.

Do you see any real use for SEARCH INTHREAD or THREAD algo1 INTHREAD  
algo2 commands?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080131/38ffc04e/attachment.sig>

Timo Sirainen writes:
> The main use I see for INTHREAD is to let client display a list of 
> threads where a search condition matches.

I see. (That's my second purpose, too.)

> This would be done with THREAD algorithm .. INTHREAD same-algorithm .. 
> command.

I thought of SEARCH INTHREAD for that. That gives a more natural 
fallback to servers without INTHREAD.

> And since they use the same algorithms, it's most likely possible to 
> optimize for that (I haven't thought of how yet).

Maybe. Not for me: My code will be a bit faster and use less disk space 
if everyone uses the same algorithm, but if two algorithms are used, it 
doesn't matter whether they're used by the same or by two different 
clients.

> But if the INTHREAD needs to work with different algorithm than THREAD 
> or if SEARCH INTHREAD is allowed, it can't use the THREAD's optimized 
> code path, requiring an alternative nonoptimized code path which will 
> be rarely (if ever) used.
>
> Do you see any real use for SEARCH INTHREAD

Yes. But I also want INTHREAD in the search key used to control mailbox views.

> or THREAD algo1 INTHREAD algo2 commands?

No that. Not at all.

Arnt

Arnt Gulbrandsen writes:
> Timo Sirainen writes:
>> This would be done with THREAD algorithm .. INTHREAD same-algorithm 
>> .. command.
>
> I thought of SEARCH INTHREAD for that. That gives a more natural 
> fallback to servers without INTHREAD.

Hm, maybe not. I could argue both sides of that.

Arnt