I can understand this, and appreciate the concern, but there are ways 
we could alleviate that, by delivering the page in chunks, or even by 
showing the first message and then clickable headers to load the 
others (via ajax if available). Rich functionality is going to be 
expensive sometimes; if we're going to have features like this I think 
we should go ahead and make them work the way users expect them to.



That said, I'm moving this back to Bogus and all of that can obviously 
wait for specific threading enhancements both to the mailbox view and 
the thread view. I have no problem with it waiting for the Horde 4 
MIME library as well.

Rendering a healthy size thread of large messages could potentially be 
*very* resource intensive (i.e. imagine all messages are PGP 
encrypted) - Thus the original design decision.



Obviously, this could be an enhancement.  But #1) it should not be the 
default, and #2) this should probably wait until the MIME library can 
be rewritten anyway.

But it might be an enhancement, no? If we want to have "conversations" 
like support, showing just the thread summary when sorting by thread, 
then having a fuller-fledged thread view would be essential.

Ok, I just was making sure that this is not a bug.

That's the way I coded it (we get the body part to show via 
$contents->findBody() instead of using MIME_Viewer).  If I remember 
correctly, this choice was explicitly made because the thread view was 
meant to be a quick/easy way of looking through the thread rather than 
a complete viewing solution for each message.

I don't know if this is the intended behaviour, but I just noticed 
that the thread view always shows the text part of 
multipart/alternative messages, even if you configured the html viewer 
to render inline.