<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Caching large HTML elements in the Browser&#8217;s document cache</title>
	<atom:link href="http://damianblog.com/2007/06/24/browser-cache/feed/" rel="self" type="application/rss+xml" />
	<link>http://damianblog.com/2007/06/24/browser-cache/</link>
	<description>.NET from Geneva, Switzerland</description>
	<lastBuildDate>Mon, 07 May 2012 06:33:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Robforhq</title>
		<link>http://damianblog.com/2007/06/24/browser-cache/comment-page-1/#comment-118</link>
		<dc:creator>Robforhq</dc:creator>
		<pubDate>Sat, 01 Dec 2007 10:33:11 +0000</pubDate>
		<guid isPermaLink="false">http://damianblog.com/2007/06/24/browser-cache/#comment-118</guid>
		<description>You have the natural advantage in  &lt;a href=&quot;debt-consolidation-adviser.net&quot; rel=&quot;nofollow&quot;&gt;debt settlement services&lt;/a&gt; , which may be appropriate for debtors with ...
 Great Solution</description>
		<content:encoded><![CDATA[<p>You have the natural advantage in  <a href="debt-consolidation-adviser.net" rel="nofollow">debt settlement services</a> , which may be appropriate for debtors with &#8230;<br />
 Great Solution</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lars Kermode</title>
		<link>http://damianblog.com/2007/06/24/browser-cache/comment-page-1/#comment-117</link>
		<dc:creator>Lars Kermode</dc:creator>
		<pubDate>Mon, 25 Jun 2007 12:12:01 +0000</pubDate>
		<guid isPermaLink="false">http://damianblog.com/2007/06/24/browser-cache/#comment-117</guid>
		<description>Hi Damian,

Thanks for this great tip. I was recently confronted to a similar issue (why on earth would you want a pull-down with thousands of entries... but hey, not my decision!). Using the browser&#039;s cache works best in a controlled environment such as an Intranet, where you can be sure that neither the browser settings, nor proxy servers interfere with the process. On the Internet however, you cannot be sure of the results.

I have looked into a couple alternative methods, with various degrees of success:

1. Using the browser&#039;s native persistent storage. This is a very browser specific solution, so your mileage will vary. In IE 5 and above, this is implemented as a behavior. There are several behaviors for persistence, the most interesting one being userData, which enables  persisting custom data to a local XML file. Note however that the size of the storage is limited according to the security zone (up to 10Mb per domain) (http://msdn2.microsoft.com/en-us/library/ms531424.aspx). Obviously, data is persistent across sessions.
In Firefox, local persistence is implemented using DOM persistence using the WHATWG DOM storage method (http://www.whatwg.org/specs/web-apps/current-work/#storage). This method offers up 5Mb of local storage, persistent across sessions or not.

As a side-note, my application required refresh of data at each logon, so I wasn&#039;t looking at cross-session persistence. I found IE&#039;s userData method too slow as it is not memory-based, unlike Firefox&#039;s DOM sessionStorage.

2. Flash local shared object. Browsers with Flash 6 and above can take advantage of Flash cookies (http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_16194) to persist data. Flash is nearly ubiquitous, and presents a nice and easy uniform cross-browser interface. The Dojo toolkit implements such a method and provides the associated .swf Flash file (http://dojotoolkit.org). Up to 100Kb can be strored without user intervention. Above that, the user will be prompted once to accept or deny the storage request.

For my needs (more than 100K storage), the user prompting with Flash was a show-stopper, so I settled for the first method. The user experience is not as good in IE since the data is not stored in memory, but it is still an order of magnitude faster that downloading the whole dataset upon each refresh of the page.

There is a detailed blog entry about the various techniques here: http://www.niallkennedy.com/blog/archives/2007/01/ajax-performance-local-storage.html

Once again, there is no &#039;one size fits all&#039; solution. At the end of the day, it really boils down to adequacy with your application and its environment.

Lars</description>
		<content:encoded><![CDATA[<p>Hi Damian,</p>
<p>Thanks for this great tip. I was recently confronted to a similar issue (why on earth would you want a pull-down with thousands of entries&#8230; but hey, not my decision!). Using the browser&#8217;s cache works best in a controlled environment such as an Intranet, where you can be sure that neither the browser settings, nor proxy servers interfere with the process. On the Internet however, you cannot be sure of the results.</p>
<p>I have looked into a couple alternative methods, with various degrees of success:</p>
<p>1. Using the browser&#8217;s native persistent storage. This is a very browser specific solution, so your mileage will vary. In IE 5 and above, this is implemented as a behavior. There are several behaviors for persistence, the most interesting one being userData, which enables  persisting custom data to a local XML file. Note however that the size of the storage is limited according to the security zone (up to 10Mb per domain) (<a href="http://msdn2.microsoft.com/en-us/library/ms531424.aspx" rel="nofollow">http://msdn2.microsoft.com/en-us/library/ms531424.aspx</a>). Obviously, data is persistent across sessions.<br />
In Firefox, local persistence is implemented using DOM persistence using the WHATWG DOM storage method (<a href="http://www.whatwg.org/specs/web-apps/current-work/#storage" rel="nofollow">http://www.whatwg.org/specs/web-apps/current-work/#storage</a>). This method offers up 5Mb of local storage, persistent across sessions or not.</p>
<p>As a side-note, my application required refresh of data at each logon, so I wasn&#8217;t looking at cross-session persistence. I found IE&#8217;s userData method too slow as it is not memory-based, unlike Firefox&#8217;s DOM sessionStorage.</p>
<p>2. Flash local shared object. Browsers with Flash 6 and above can take advantage of Flash cookies (<a href="http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_16194" rel="nofollow">http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_16194</a>) to persist data. Flash is nearly ubiquitous, and presents a nice and easy uniform cross-browser interface. The Dojo toolkit implements such a method and provides the associated .swf Flash file (<a href="http://dojotoolkit.org" rel="nofollow">http://dojotoolkit.org</a>). Up to 100Kb can be strored without user intervention. Above that, the user will be prompted once to accept or deny the storage request.</p>
<p>For my needs (more than 100K storage), the user prompting with Flash was a show-stopper, so I settled for the first method. The user experience is not as good in IE since the data is not stored in memory, but it is still an order of magnitude faster that downloading the whole dataset upon each refresh of the page.</p>
<p>There is a detailed blog entry about the various techniques here: <a href="http://www.niallkennedy.com/blog/archives/2007/01/ajax-performance-local-storage.html" rel="nofollow">http://www.niallkennedy.com/blog/archives/2007/01/ajax-performance-local-storage.html</a></p>
<p>Once again, there is no &#8216;one size fits all&#8217; solution. At the end of the day, it really boils down to adequacy with your application and its environment.</p>
<p>Lars</p>
]]></content:encoded>
	</item>
</channel>
</rss>

