<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Sat, 18 May 2013 09:52:03 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Kevin Schroeder's Blog: Pre-caching FTW]]></title>
      <guid>http://www.phpdeveloper.org/news/15703</guid>
      <link>http://www.phpdeveloper.org/news/15703</link>
      <description><![CDATA[<p>
In <a href="http://www.eschrade.com/page/precaching-4d25dc90">this new post</a> to his blog <i>Kevin Schroeder</i> suggests that there's something even better than doing the typical caching inline (request, write to cache) - pre-caching.
</p>
<blockquote>
I just had an epiphany.  I've talked about <a href="http://www.eschrade.com/page/precaching-content-with-zend_cache_manager-zend-server-queue-4bd1fdd4">pre-caching content before and the benefits thereof</a> before.  But this is the first time I realized not only that there are benefits, but that doing it is BETTER than caching inline.  Let me sum up... no, there is to much.  Let me explain.
</blockquote>
<p>
He gives an example of how a typical application might cache - when it finds a "miss" for the data it's trying to pull. A simple cache is easy, but what happens if it uses a configuration value that could change (like the username/password in his second example). Pre-caching would eliminate the risk since the setting would be known to be valid when the cache is generated.
</p>]]></description>
      <pubDate>Fri, 07 Jan 2011 11:16:57 -0600</pubDate>
    </item>
  </channel>
</rss>
