From: Sylvain Wallez (sylvain.wallez@anyware-tech.com)
Date: 10/08/2004 - 13:08
Robin Berjon wrote:
>Sylvain Wallez wrote:
>
>
>>Robin Berjon wrote:
>>
>>
>>>Yeech! Il faudrait au moins que ce soit application/xml, text/xml est
>>>une mauvaise idée en voie de déprécation!
>>>
>>>
>>sed s/"text\/xml"/"application\/xml" sitemap.xmap !!
>>
>>
>
>Oui, je me doute bien, mais je tenais à le préciser: text/xml a beaucoup
>de problèmes (notamment avec les encodages) et le plus tôt il
>disparaîtra, le mieux ce sera. La dernière version du RFC correspondant
>s'en débarrasse, bientôt il n'existera plus.
>
>
>
>>>Tu veux dire que c'est le serializer qui gère la pipeline? Ca me parait
>>>étrange, mais pour le SAX c'est peut-être plus pratique.
>>>
>>>
>>Exactement: le pipeline étant constitué d'une chaine [ generator,
>>transformer*, serializer ] de composants SAX, donc fonctionnant en
>>streaming, on ne peut démarrer la production d'événements SAX dans le
>>generator que lorsque la chaîne est complète, c'est à dire lorqu'on y a
>>mis un serializer.
>>
>>
>
>Nous sortons complétement de la question d'origine, mais c'est
>intéressant (au moins pour moi :). Je serais curieux de savoir quelle
>est la perception de l'utilité du passage complet à SAX dans Cocoon,
>maintenant que ça doit faire deux ans (trois?) que c'est là .
>
>
L'enchainement de transformations DOM utilisé par Cocoon 1 s'est avéré
être un frein fort à la montée en charge des applications, parce que le
traitement d'une requête entrainait la création d'une forêt d'arbres
d'objets (un arbre par élément de la chaine) qui était mise à la
poubelle à la fin de la requête. Grosse consommation mémoire, et
beaucoup de CPU dépensé en allocation/désallocation. Par ailleurs,
certaines transformations ne font que des modifications locales du
document (genre internationalisation, réécriture de liens, etc).
Cette raison à poussé à l'utilisation de SAX pour Cocoon 2. Les
transformations "à la volée" (sans restructuration) se font en streaming
SAX, et les transformations qui ont besoin de faire une exploration
profonde de l'arbre XML peuvent recréer un DOM local si besoin est. Au
passage, XSLT est le principal transformer qui a besoin de l'arbre
complet, mais les moteurs Java (Xalan et Saxon) utilisent une structure
plus efficace que le DOM (ça s'appelle DTM chez Xalan).
>L'idée est de comparer les fiches. La suggestion de tout basculer en SAX revient régulièrement dans la communauté AxKit, mais se fait régulièrement descendre (je dois avouer que je ne suis pas le dernier à être contre en attente de raisons suffisantes) parce qu'elle semble n'apporter que peu (une latence perçue par l'utilisateur amoindrie par l'arrivée plus rapide du début du contenu) par rapport à son coût (une orthogonalité plus faible de la pipeline, et un temps de traitement global plus long, principalement du à ce que les appels de méthode coûtent cher dans un langage dynamique -- problème que ne devrait pas avoir Cocoon).Généralement le temps de latence perçue est considéré comme suffisament faible pour que le jeu n'en vaille pas la chandelle, surtout qu'il est complétement perdu pour certaines sérialisations, notamment dans le cadre de publications vers des environements mobiles.
>
>
La réduction du temps de latence n'est pas l'argument principal, même si
c'est un bonus dans certains cas, peu nombreux, parce que dès qu'on a
une XSL dans la chaîne, le moteur a besoin de recréer une arborescence
locale ce qui a pour effet de bufferiser ce qui est produits par les
composants en amont dans la chaine.
Le bonus a été dans une augmentation très substantielle des temps de
réponse et une diminution non moins substantielle des pics d'utilisation
mémoire. Mais il est vrai qu'un appel de méthode Java n'est pas bien
coûteux, surtout depuis qu'on a les JVM Hotspot.
>De surcroît AxKit 2.0 (encore très alpha) se base sur Apache 2.0 et exploite ses buckets pour gagner en performances -- un approche qui se marie mal au SAX. Evidemment c'est un argument qui ne concerne pas Cocoon puisqu'il ne fonctionne pas comme un module Apache.
>
>
Qu'est-ce que c'est, les buckets de httpd 2.0 ?
>Donc je suis curieux, as-tu une opinion sur le sujet?
>
>
>>Ok, je comprends. Une chose qui a déjà été évoquée sur les listes Cocoon est d'écrire un "XSLSerializer" qui permettrait donc l'utilisation de <xsl:output>. En attendant que ça démange quelqu'un suffisamment pour qu'il écrive ce composant, on continue avec ce qu'on a ;-)
>>
>>
>
>Je suppose que si un jour je dois utiliser Cocoon, c'est la première chose que je ferai (ça, et un BinaryXMLSerializer) ;)
>
>
Je pourrais même l'écrire si ça peut te faire utiliser Cocoon ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 31/08/2004 - 11:12 UTC
webmaster@xmlfr.org
| 
