I'm going to reject this simply because there is nothing concrete we 
can grab out of this ticket.  As previously said, we cache all mailbox 
information already in a session.  And my plan is to eventually (at 
this point, after DIMP 1.0) convert the preview rendering code to a JS 
template based solution (like we do with the message list) to reduce 
the amount of HTML code that is generated and sent by the server.   
After this is done, we will only be sending message information from 
the server, so these JSON object should be easily cacheable.

Well, FWIW, we currently cache all mailbox buffers in the current 
session on the browser.

Michael, could you think about this as part of the other performance 
stuff you're looking at with SAPO, and then close or update the ticket 
at your discretion?

Deleting a message, paging past it in the viewport, replying to a 
message - it'd be much quicker, for example, to quote text on the 
client side, or even if we want to keep all the quoting logic server 
side, to pass the message being quoted into a server-side method 
instead of hitting the imap server for its body again.



Also, the more stuff we can cache on the client instead of on the 
server, the better we'll scale on the server.

I'm not sure. How often do you view the same message twice during a 
session and need additional performance for that? We already use 
caching for performance-important tasks like the viewport buffer.

And how would this work across logins?

What about using something like this:

http://dev.webframeworks.com/projects



... to cache rendered message bodies (obviously need a cache id that 
includes preferences, but that seems doable), mailboxes, etc. Maybe 
even the folder list between logins...