<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: Cache-uri</title>
	<atom:link href="http://www.inphpwetrust.com/cache/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.inphpwetrust.com/cache/</link>
	<description>click-click, copy, click-click, paste ...</description>
	<lastBuildDate>Thu, 10 Jun 2010 15:44:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: SaltwaterC</title>
		<link>http://www.inphpwetrust.com/cache/comment-page-1/#comment-79</link>
		<dc:creator>SaltwaterC</dc:creator>
		<pubDate>Tue, 30 Mar 2010 14:04:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=157#comment-79</guid>
		<description>Printre altele, aș recomanda un factory pattern design pentru a implementa o bibliotecă de cache. Face codul ce lucrează cu partea de caching să nu fie dependent de un anume subsistem. În acest caz, migrarea de la APC la Memecache sau invers presupune efort minim (preferabil variabilă de configurare pentru a fi DRYer). Nu strică implementarea de namespaces pentru cache, direct în bibliotecă dacă nu există suport nativ. Spre exemplu, Zend Data Cache (disponibil cu stiva Zend Server/Zend Server Community Edition) are suport nativ pentru namespaces, deși oferă și un wrapper pentru API-ul APC (aplicațiile pot fi migrate cu zero modificări). Dacă pe mașina respectivă sunt aplicații multiple ce folosesc cache comun, situație întâlnită în unele cazuri, există riscul coliziunilor pentru cache key.

De altfel, citit acest articol, mi-a mai venit o idee pentru a reduce repetitivitatea din cod: getter-ul din cache (evident, nu mă refer la __get()) să fie abstract și să apeleze prin callback metoda ce generează conținutul cache-ului. În loc de:

if ( ! $value = $cache-&gt;get($key))
{
    $value = $object-&gt;get_data($param1, [$param2], ...);
    $cache-&gt;set($key, $value);
}

lucrurile s-ar simplifica la $value = $cache-&gt;get($key, array($object, &#039;get_data&#039;), $param1, [$param2], ...);

pentru fiecare apel către getter, iar acel if() să fie executat intern, transparent față de programator.</description>
		<content:encoded><![CDATA[<p>Printre altele, aș recomanda un factory pattern design pentru a implementa o bibliotecă de cache. Face codul ce lucrează cu partea de caching să nu fie dependent de un anume subsistem. În acest caz, migrarea de la APC la Memecache sau invers presupune efort minim (preferabil variabilă de configurare pentru a fi DRYer). Nu strică implementarea de namespaces pentru cache, direct în bibliotecă dacă nu există suport nativ. Spre exemplu, Zend Data Cache (disponibil cu stiva Zend Server/Zend Server Community Edition) are suport nativ pentru namespaces, deși oferă și un wrapper pentru API-ul APC (aplicațiile pot fi migrate cu zero modificări). Dacă pe mașina respectivă sunt aplicații multiple ce folosesc cache comun, situație întâlnită în unele cazuri, există riscul coliziunilor pentru cache key.</p>
<p>De altfel, citit acest articol, mi-a mai venit o idee pentru a reduce repetitivitatea din cod: getter-ul din cache (evident, nu mă refer la __get()) să fie abstract și să apeleze prin callback metoda ce generează conținutul cache-ului. În loc de:</p>
<p>if ( ! $value = $cache-&gt;get($key))<br />
{<br />
    $value = $object-&gt;get_data($param1, [$param2], &#8230;);<br />
    $cache-&gt;set($key, $value);<br />
}</p>
<p>lucrurile s-ar simplifica la $value = $cache-&gt;get($key, array($object, &#8216;get_data&#8217;), $param1, [$param2], &#8230;);</p>
<p>pentru fiecare apel către getter, iar acel if() să fie executat intern, transparent față de programator.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aplicatie OAuth &#171; Informatii Profesionale</title>
		<link>http://www.inphpwetrust.com/cache/comment-page-1/#comment-77</link>
		<dc:creator>Aplicatie OAuth &#171; Informatii Profesionale</dc:creator>
		<pubDate>Wed, 24 Mar 2010 11:23:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=157#comment-77</guid>
		<description>[...] de sine statatoare si care sa functioneze corect in toate cazurile. O modalitate de a face un cache al mesajelor si adaugarea unor functionalitati JavaScript pentru o experienta a utilizatorului mai [...]</description>
		<content:encoded><![CDATA[<p>[...] de sine statatoare si care sa functioneze corect in toate cazurile. O modalitate de a face un cache al mesajelor si adaugarea unor functionalitati JavaScript pentru o experienta a utilizatorului mai [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: In PHP we Trust &#187; Aplicație Twitter folosind OAuth</title>
		<link>http://www.inphpwetrust.com/cache/comment-page-1/#comment-74</link>
		<dc:creator>In PHP we Trust &#187; Aplicație Twitter folosind OAuth</dc:creator>
		<pubDate>Thu, 18 Mar 2010 20:02:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=157#comment-74</guid>
		<description>[...] de sine stătătoare si care sa funcționeze corect în toate cazurile. O modalitate de a face un cache al mesajelor și adăugarea unor funcționalități JavaScript pentru o experientă a [...]</description>
		<content:encoded><![CDATA[<p>[...] de sine stătătoare si care sa funcționeze corect în toate cazurile. O modalitate de a face un cache al mesajelor și adăugarea unor funcționalități JavaScript pentru o experientă a [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: theheartcollector</title>
		<link>http://www.inphpwetrust.com/cache/comment-page-1/#comment-59</link>
		<dc:creator>theheartcollector</dc:creator>
		<pubDate>Fri, 16 Oct 2009 17:04:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=157#comment-59</guid>
		<description>În locul funcţiei resetCache, în anumite situaţii eu propun folosirea unei alte funcţii pe care o numim, de exemplu flagDirty, funcţie care doar va marca cache-ul ca inconsistent, acesta urmând să fie reconstruit doar în momentul în care se declanşează un eveniment care cere informaţii din el. Desigur, ambele variante au dezavantajele lor. Varianta mea, de exemplu, s-ar putea să frustreze clientul care va declanşa un eveniment care va reconstrui cache-ul, în schimb, varianta ta s-ar putea să supraîncarce serverul bazei de date într-un moment inoportun, cerând refacerea cache-ului respectiv, deşi, în momentul respectiv, informaţiile din el nu erau accesate. Eu presupun că site-urile imense, de exemplu Amazon, folosesc diverse combinaţii ale acestor funcţii, pentru a obţine rezultate cât mai bune...</description>
		<content:encoded><![CDATA[<p>În locul funcţiei resetCache, în anumite situaţii eu propun folosirea unei alte funcţii pe care o numim, de exemplu flagDirty, funcţie care doar va marca cache-ul ca inconsistent, acesta urmând să fie reconstruit doar în momentul în care se declanşează un eveniment care cere informaţii din el. Desigur, ambele variante au dezavantajele lor. Varianta mea, de exemplu, s-ar putea să frustreze clientul care va declanşa un eveniment care va reconstrui cache-ul, în schimb, varianta ta s-ar putea să supraîncarce serverul bazei de date într-un moment inoportun, cerând refacerea cache-ului respectiv, deşi, în momentul respectiv, informaţiile din el nu erau accesate. Eu presupun că site-urile imense, de exemplu Amazon, folosesc diverse combinaţii ale acestor funcţii, pentru a obţine rezultate cât mai bune&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
