[#4657] Use client-side caching of more data for performance
Summary Use client-side caching of more data for performance
Queue DIMP
Type Enhancement
State Rejected
Priority 1. Low
Owners Michael Slusarz <slusarz (at) horde (dot) org>
Requester Chuck Hagenbuch <chuck (at) horde (dot) org>
Created 11/13/2006 (545 days ago)
Due
Updated 12/24/2007 (139 days ago)
Assigned 04/13/2007 (394 days ago)
Resolved 12/24/2007 (139 days ago)
Attachments
Milestone
Patch

History
12/24/2007 Michael Slusarz Comment #6
State ⇒ Rejected
Reply to this comment
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.
04/16/2007 Michael Slusarz Comment #5 Reply to this comment
Well, FWIW, we currently cache all mailbox buffers in the current session on the browser.
04/13/2007 Chuck Hagenbuch Comment #4
State ⇒ Assigned
Assigned to Michael Slusarz
Reply to this comment
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?
11/14/2006 Chuck Hagenbuch Comment #3 Reply to this comment
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.
11/14/2006 Jan Schneider Comment #2 Reply to this comment
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?
11/13/2006 Chuck Hagenbuch Comment #1
Priority ⇒ 1. Low
State ⇒ Feedback
Summary ⇒ Use client-side caching of more data for performance
Queue ⇒ DIMP
Type ⇒ Enhancement
Reply to this comment
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...