<?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: An AJAX Caching Strategy</title>
	<atom:link href="http://ajaxian.com/archives/an-ajax-caching-strategy/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/an-ajax-caching-strategy</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 17 May 2012 07:43:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Allen</title>
		<link>http://ajaxian.com/archives/an-ajax-caching-strategy/comment-page-1#comment-8858</link>
		<dc:creator>Allen</dc:creator>
		<pubDate>Fri, 05 May 2006 17:32:44 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/an-ajax-caching-strategy#comment-8858</guid>
		<description>@James
At first glance your 100% correct, and when it comes down to it, standard practices in ajax caching (i.e. its nonexistant heh) will do the trick.  But when your dealing with sending / receiving large amounts of data, triggering queries each time, etc, and on a large scale, you can run into problems.  Max connections can be an issue in itself (yeah i know, its a stretch).  There is no end all cache solution for Ajax, so my writeup will cover as many specialty niche&#039;s / cases as possible.

Also, there are implications on the client side as well, if a user has already looked up data with an xhr call, why should they ever have to look it up again?  It *should* be cached if it can be.</description>
		<content:encoded><![CDATA[<p>@James<br />
At first glance your 100% correct, and when it comes down to it, standard practices in ajax caching (i.e. its nonexistant heh) will do the trick.  But when your dealing with sending / receiving large amounts of data, triggering queries each time, etc, and on a large scale, you can run into problems.  Max connections can be an issue in itself (yeah i know, its a stretch).  There is no end all cache solution for Ajax, so my writeup will cover as many specialty niche&#8217;s / cases as possible.</p>
<p>Also, there are implications on the client side as well, if a user has already looked up data with an xhr call, why should they ever have to look it up again?  It *should* be cached if it can be.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brandon</title>
		<link>http://ajaxian.com/archives/an-ajax-caching-strategy/comment-page-1#comment-8856</link>
		<dc:creator>Brandon</dc:creator>
		<pubDate>Fri, 05 May 2006 16:58:40 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/an-ajax-caching-strategy#comment-8856</guid>
		<description>I&#039;m interested in this and would like to see your article, Allen.</description>
		<content:encoded><![CDATA[<p>I&#8217;m interested in this and would like to see your article, Allen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James MacFarlane</title>
		<link>http://ajaxian.com/archives/an-ajax-caching-strategy/comment-page-1#comment-8844</link>
		<dc:creator>James MacFarlane</dc:creator>
		<pubDate>Fri, 05 May 2006 13:47:55 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/an-ajax-caching-strategy#comment-8844</guid>
		<description>&quot;Making HTTP requests willy-nilly from AJAX applications, however, is almost never a good idea or design decision. The server side of the equation may not be able to handle the flood of requests.&quot;

Baloney! What&#039;s the difference between an Ajax application requesting a little squirt of data, and a browser requesting an ENTIRE PAGE? If a user is going to click on something they&#039;re making a request from the server regardless. Users do that &quot;willy nilly&quot; too

A smaller data packet means the server will complete the request SOONER and be available for more requests.</description>
		<content:encoded><![CDATA[<p>&#8220;Making HTTP requests willy-nilly from AJAX applications, however, is almost never a good idea or design decision. The server side of the equation may not be able to handle the flood of requests.&#8221;</p>
<p>Baloney! What&#8217;s the difference between an Ajax application requesting a little squirt of data, and a browser requesting an ENTIRE PAGE? If a user is going to click on something they&#8217;re making a request from the server regardless. Users do that &#8220;willy nilly&#8221; too</p>
<p>A smaller data packet means the server will complete the request SOONER and be available for more requests.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Allen</title>
		<link>http://ajaxian.com/archives/an-ajax-caching-strategy/comment-page-1#comment-8839</link>
		<dc:creator>Allen</dc:creator>
		<pubDate>Fri, 05 May 2006 13:06:48 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/an-ajax-caching-strategy#comment-8839</guid>
		<description>theres so many different instances and cases where you would need to cache in ajax, and this isnt one (it should be done at the server / proxy level in this case).  I&#039;ll start working on a big caching article tonight.</description>
		<content:encoded><![CDATA[<p>theres so many different instances and cases where you would need to cache in ajax, and this isnt one (it should be done at the server / proxy level in this case).  I&#8217;ll start working on a big caching article tonight.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

