Pour te donner une id�e plus pr�cise de nos types de probl�mes, consid�rons ce classique <http://gallica.bnf.fr/>. Dans l'id�al, beaucoup de ressources, tr�s organis�es, un traffic raisonable. On h�rite d'une longue tradition de r�flexions, de classement ou d'identification en amont. L'application a une vie beaucoup plus courte que la donn�e, il ne faut pas oublier de la rendre, aussi bien voire mieux rang�e qu'elle a �t� pr�t�e.
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.
J'ai l'impression que l'URL compatible syst�me de fichiers n'est pas si
rare, du moins pour les tuyaux XML. Un sitemap Cocoon n'est il pas souvent � base de chemins droits ?
Pour r�pondre au probl�me du fichier de swap,
Pour un autre jour, rendre sa taille configurable peut �tre prudent, je n'ai pas l'impression que cela nuirait � un cocoon d�faut de par exemple fixer � 1Go... Mais pass� la limite, cela demande � g�rer les sorties.
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.
Tr�s g�n�rique, mod_cache ou nos navigateurs ne font pas diff�remment... Mais il n'y a pas de solution parfaite, cela semble le mieux pour des gros fichiers, mais pour le coeur de m�tier de cocoon, petits documents r�sultant de nombreuses transformations, le choix d'un gros fichier semble le bon.
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.
Je note, mais je ne pense pas que j'en aurais besoin, si les plus gros binaires sont g�r�s ind�pendamment.
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.
S'il on a des tuyaux avec plusieurs �tapes, et des appels en
protocole cocoon:/ , on risque de copier beaucoup d'�tats transitoires
un peu partout s'il on ne fait pas attention � son type de pipeline. Et s'il on veut plusieurs lieux de stockage, cela prends plusieurs "pipeline" � configurer ?
Pour le cas expos� en d�but de fil, ton action copy-source patch�e suffit, car il n'y a essentiellement qu'une source � v�rifier.
Pour plus g�n�rique, il me semble qu'en sitemap, une action est plus
lisible, plus configurable. Et si je ne me trompe pas, un "ModifiableSource" en destination pourrait tr�s bien �tre un XML:DB par exemple ?
Cela simpliefierait si SitemapSource pouvait r�pondre � getLastModified(). Pour l'instant, c'est "return 0;". En d�roulant l'objet Validity (quand il y a des TimeStampValidity), je trouve un lastModified qui marche pas mal. Cela permet de se passer du param�tre "depend" propos� au d�but de ce thread, du moins, quand getValidity() r�ponds quelque chose (ce qui n'a pas l'air le cas au bout du reader d'images).
Je ne sais pas pour d'autres, mais pour moi, c'est beaucoup plus simple et facile � contr�ler que du Cocoon CLI pour faire de la g�n�ration de statique.
-- Fr�d�ric Glorieux ("AJLSM", <http://ajlsm.com>)
--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
