Fr�d�ric Glorieux wrote:
Sylvain,
merci beaucoup pour ce message
<http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
> http://www.grumpykitty.biz/index.html > (origine des fonctions de > changements de couleur).
tr�s joli
http://www.ormaz.it/ http://cocoongallery.sourceforge.net/
C'est int�ressant, mais cela ne d�passe pas le millier d'images ?
La limite de 1000 est la zone tampon en m�moire. Au del� de cette limite, les entr�es plus anciennes sont swapp�es sur disque.
S'il s'agit des vignettes, pourquoi pas. Mais prenons le cas d'images retaill�es (par ex 800px) 200 � 300k, je suis inquiet de les voir s'�crire dans un seul fichier de swap, je pr�f�re les avoir quelque part. Car au cas o� l'on constate des probl�mes en exploitation, cela permet de faire des coupe-circuit par Apache direct.
Pour r�pondre au probl�me du fichier de swap, on peut utiliser l'impl�mentation filesystem du cache, qui cr�e un fichier par entr�e, avec quelques niveaux de r�pertoires pour �viter un nombre trop important de fichiers dans un seul r�pertoire. C'est l'approche utilis�e par VNUnet pour un grand nombre de sites de gros volume et � tres fort trafic, en combinaison avec mod_cache. L'utilisation de reiserfs sur Linux donne d'excellentes performances, mais cette approche est d�conseill�e sur windows qui n'arrive pas � tenir la cadence.
Sur le mod�le de l'action copy-source de Sylvain Wallez, j'ai impl�ment� un m�canisme tr�s simple de stockage contr�l� en syst�me de fichier, qui s'informe au passage si l'image source a �t� modifi�e.
Si j'ai bien compris, l'action "copy-source" copie un fichier � chaque fois qu'elle est execut�e ?
Oui.
J'ai l'impression que laisser le cache Cocoon faire son boulot tout seul comme un grand est la meilleure solution ;-)
Refaire une cache est �videmment idiot. Mon alternative �tait la suivante
* pr�g�n�ration : ImageMagick, robuste �prouv�, mais mal commode pour l'utilisateur final, pareil en dev (en fait la vignette je la voulais en 150 plut�t qu'en 96)
* cocoon � la vol�e : commode, moins d'install, tr�s bien pour prototyper, mais d�j� pr�voir 256 Mo en -Xmx, incertitude de comportement sur les masses
D'o� l'envie d'une "pr�g�n�ration � la vol�e", ou plus exactement, "g�n�ration � la demande". Cela pourrait d'ailleurs se transformer en une action qui appelle ImageMagick au cas o�.
La diff�rence entre le cache cocoon sur filesystem et une pr�g�neration est essentiellement le nom des fichiers (un code cryptique dans le cas du cache, un nom en rapport avec l'URL dans le cas de la pr�g�n�ration).
On est ici dans un cas particulier o� le contenu renvoy� ne d�pend que de l'URL de la requ�te, et pas d'autres param�tres comme la langue, l'�tat de la session ou autres. Un utilisateur (d�sol�, je n'ai pas retrouv� le message original) a expliqu� une approche int�ressante dans cette configuration : une impl�mentation particuli�re de pipeline est utilis�e, qui �crit sa production sur disque en utilisant l'URL comme chemin de fichier. En frontal de Cocoon, un httpd utilise mod_rewrite : si le fichier demand� existe, il est servi par httpd, autrement on redirige sur Cocoon, et le fichier sera cr��. G�n�ration � la demande ! Malgr� tout, les documents d'origine sont amen�s � changer, et c'est la partie de l'appli qui g�re le contenu qui efface les fichiers pr�g�n�r�s lorsque leur source change.
J'ai l'impression que �a ressemble � ce que tu d�cris.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
