<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="http://bugs.horde.org/themes/feed-rss.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
 <channel>
  <title>Use client-side caching of more data for performance</title>
  <pubDate>Sat, 05 Jul 2008 00:03:44 -0400</pubDate>
  <link>http://bugs.horde.org/ticket/4657</link>
  <atom:link rel="self" type="application/rss+xml" title="Use client-side caching of more data for performance" href="http://bugs.horde.org/ticket/4657/rss" />
  <description>Use client-side caching of more data for performance</description>

  
  
  <item>
   <title>What about using something like this:
http://dev.webframewo</title>
   <description>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...</description>
   <pubDate>Mon, 13 Nov 2006 17:19:42 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/4657#t26021</link>
  </item>
  <item>
   <title>I'm not sure. How often do you view the same message twice d</title>
   <description>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?</description>
   <pubDate>Tue, 14 Nov 2006 04:01:02 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/4657#t26030</link>
  </item>
  <item>
   <title>Deleting a message, paging past it in the viewport, replying</title>
   <description>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.</description>
   <pubDate>Tue, 14 Nov 2006 12:07:56 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/4657#t26051</link>
  </item>
  <item>
   <title>Michael, could you think about this as part of the other per</title>
   <description>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?</description>
   <pubDate>Fri, 13 Apr 2007 12:01:52 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/4657#t31622</link>
  </item>
  <item>
   <title>Well, FWIW, we currently cache all mailbox buffers in the cu</title>
   <description>Well, FWIW, we currently cache all mailbox buffers in the current session on the browser.</description>
   <pubDate>Mon, 16 Apr 2007 19:12:49 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/4657#t31779</link>
  </item>
  <item>
   <title>I'm going to reject this simply because there is nothing con</title>
   <description>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.</description>
   <pubDate>Mon, 24 Dec 2007 02:49:34 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/4657#t40240</link>
  </item>
  

 </channel>
</rss>
