Salut Pierrick,
[ma r�ponse n'est pas une r�ponse de cocooniste]
Tr�s utile, on ferait vite secte.
> Ce qu'il faut cacher, c'est le timestamp de ton image "grande taille".
>> J'ai l'impression qu'une b�te comparaison de dates de fichiers, >> m�me si cela >> demande un acc�s disque sera globalement plus efficace pour mon >> probl�me initial, g�n�rer des vignettes sur des images.
> Pas d'accord : trop long. Voir strat�gies expos�es ci-dessus.
Il y a un truc dont je voudrais �tre s�r, comment la cache cocoon fait pour v�rifier qu'une ressource n'a pas �t� modifi�e ? Pour le cas typique d'une source XML transform�e par une XSL, quelles que soient les abstractions, cela revient bien � faire un "lastModified()" sur le fichier de la source XML et de l'XSL ?
<http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
... et difficilement portables (il faut un environnement graphique). Soit tu charges les JAI (lourd et toujours propri�taire mais n�anmoins tr�s efficaces), soit tu vas chercher une biblioth�que graphique pur Java.
Mon exp�rience avec JAI est ancienne, j'en ai gard� le souvenir d'une API tr�s peu commode. Ceci dit, depuis il y a une t�che Ant qui utilise <http://ant.apache.org/manual/OptionalTasks/image.html>, il y a certainement du bon code � imiter <http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/optional/image/Image.java?view=markup>, mais bon, JAI n'est toujours pas trivial, voyez cela pour seulement redimensionner <http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/types/optional/image/Scale.java?view=markup>.
Et de toute fa�on cela ne marche qu'en SUN aussi ?
L'apport en performances de JAI me semble d�cisif pour un GUI ou une applet, o� l'utilisateur reste en JAVA, et veut une r�ponse rapide. Cela semble tr�s adapt� � des applications de traitements tr�s sp�cifiques d'images (voir <http://java.sun.com/products/java-media/jai/success/>), par contre, pour une appli g�n�rique, je ne vois pas que cela puisse concurrencer photoshop.
Pour les op�rations de pr�g�n�ration, le temps est moins critique, mais j'avais observ� (cela date), que ImageMagick �tait 2 � 3 fois plus rapide pour des conversion tiff vers jpg, plus facile � scripter, et avec beaucoup plus de possibilit�s. L'inconv�nient, c'est un binaire sp�cifique � installer par poste. La t�che ant pourrait faire revoir ce constat, mais cela fait aussi JAI � installer.
En serveur, en g�n�ration � la demande, la pression sur la machine est plus diffuse. Le moment critique est par exemple la page de vignettes. J'ai test� l'ImageReader de Cocoon sur 100 nouvelles images � g�n�rer. S'il est dans les 64Mo standard java, une image sur 7 � 10 passe � la trappe, et cocoon met en cache des fichiers corrompus (d'o� ma confiance relative envers la cache cocoon pour ce genre d'op�rations).
Avec 256Mo, �a passe, mais je n'ai pas test� avec 100 pages diff�rentes avec chacune 100 vignettes � g�n�rer.
> (pas de probl�me en cas de serveur statique) > Comment veux-tu faire autrement ? En service Web, le LRU, c'est encore > ce qui marche le mieux, non ? En fait l'id�al, c'est un "LRU boost�" > (derni�re consultation * nombre de consultations).
D'o�, avoir mes images redimensionn�es en fichiers, laisser Apache ou Cocoon s'optimiser l�-dessus.
-- 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]
