dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: [xhtml] Objectifs
From: Sylvain Wallez (sylvain.wallez@anyware-tech.com)
Date: 30/12/2003 - 23:01
[j'essaye de rattraper le trafic étonnant pendant cette période plutôt
calme par ailleurs ;-) ]
Frédéric Glorieux wrote:
> > ("cool URIs don't change").
>
>C'est un principe cardinal.
>
>
>
>>Il est également intéressant de considérer Cocoon comme un middleware
>>qui permet de masquer la structure physique du site (qui peut être
>>amenée à changer) pour assurer la permanence des URIs
>>
>>
>
>Je n'ai pas assez d'expérience autre que notre Cocoon/SDX pour avoir un
>avis objectif sur la chose. Par contre j'ai souvent eu le besoin de
>donner une vue statique sur une collection, il y a aussi le problème des
>performances Cocoon. D'où cette envie de donner le plus possible au
>statique, et de ne demander que le minimum au dynamique.
>
>
Plusieurs réponses à ces soucis de performances, de la philosophie aux
mains dans le cambouis :
"Premature optimization is the root of all evil" (Donald Knuth). Ne
complexifions pas toute l'architecture à partir d'hypothèses non
vérifiées sur les performances. J'ai eu l'occasion de le vérifier
plusieurs fois dans ma vie professionnelle.
Les performances de Cocoon sont liées à la complexité des traitements
(longueur des pipelines) et, dans le cas d'un site de publication comme
XMLfr, à la mise en cache de ces traitements. Je connais peu SDX, mais
j'ai cru comprendre qu'il reposait beaucoup sur les XSPs, qui ne sont
pas naturellement cachables (bien qu'on puisse le faire). Et puis tu as
peut-être de mauvais souvenirs des performances de Cocoon 1.x qui
étaient effectivement pas terribles...
Au delà du cache interne de Cocoon, les performances et la tenue en
charge sont grandement améliorées en mettant en frontal de Cocoon un
serveur httpd Apache avec le mod_cache. Les pipelines Cocoon peuvent
spécifier une date d'expiration pour leur production, et le cache de
httpd ne fera aucune nouvelle requête à Cocoon tant que le délai
d'expiration ne sera pas atteint.
Et pour obtenir des performances encore plus élévées, on peut faire une
utilisation conjointe astucieuse de mod_rewrite et Cocoon : pour une URL
donnée, on commence par regarder si le fichier correspondant existe. Si
oui, on le renvoie. Si non, on route la requête sur Cocoon, qui renvoie
le résultat *et* l'enregistre sur disque. Au coup d'après, on ne lui
redemande donc rien. Par ailleurs, chaque modification de la base
documentaire entraine l'effacement des fichiers sur disque qui en
dépendent (c'est le point délicat de cette approche). C'est expliqué sur
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104452461431897&w=2
A noter que cette dernière approche revient exactement à la génération
batch, sauf qu'elle est faite à la demande.
Voilà. Tout ça pour dire qu'au moins dans un premier temps, il ne faut
pas se contraindre dans l'utilisation de Cocoon ;-)
Par ailleurs, il faut savoir que de très gros sites sont motorisés par
Cocoon, comme des portails pour téléphones mobiles, certains recevant
3,5 millions de requêtes/jour !!
>>Oui. Entre autres avantages, subversion permet d'associer des propriétés
>>aux documents qu'il gère et gère également l'historique de ces
>>propriétés. C'est une fonctionnalité que nous utilisons abondamment dans
>>l'interface rédaction de XMLfr.
>>
>>
>
>Cette interface de rédaction fera-t-elle partie de la distribution ? Par
>exemple, je n'ai pas bien compris si vous vouliez conserver votre DTD
>newsML ?
>
>Même pour moi, je lâche de plus en plus l'éditeur XML. En ce moment je
>prescris des configuration OpenOffice 1.1 avec des XSL maison et des
>templates pour enregistrer des articles (xhtml + méta-données Dublin
>Core). On reste dans une interface connue, pleine de commodités, avec en
>particulier la correction orthographique en cours de rédaction. Il est
>aussi imaginable de pouvoir faire l'édition en ligne dans le genre du
>linotype de Mazzochi (j'ai étudié le principe aussi, dans l'esprit de
>xopus, profiter d'une propriété .contentEditable dans le navigateur).
>
Entièrement d'accord ! Ecrire une doc en XML direct est une expérience
très douloureuse. Il faut du "WYSIWIS" (what you see is what you
structure), et aussi bien OpenOffice que les éditeurs in-browser sont à
préconiser à la fois par l'ergonomie qu'ils apportent que par le fait
qu'ils permettent la récupération facile d'un document structuré.
>En fait, je crois de plus en plus à l'accés multiple en édition, et depuis
>que je vois Mazocchi parti dans Slide, je me dis qu'il faut rester
>compatible CMS/Webdav.
>
>
Ca, c'est encore une autre histoire! Stefano s'est investi sur Slide
dans le cadre de ses travaux sur la JSR-170 (Java Content Repository
API), qui vise à être le JDBC de la gestion de contenu. Ce sera en
quelque sorte le pendant "programmatique" en Java de ce qu'est WebDAV au
niveau protocole.
A noter que Cocoon peut être un serveur WebDAV : il y a une "sitemap
WebDAV" dans le bloc éponyme. Ca permet de proposer via WebDAV des
documents "virtuels" plus adaptés à l'édition que le format réel du
contenu (comme OpenOffice, notamment).
>>Oui, mais également le fait (par exemple) de trier les articles (par
>>date, catégorie, auteur). C'est à creuser, mais je suis certain que l'on
>>doit pouvoir améliorer l'ergonomie du site de cette manière.
>>
>>
>
>Vu désormais la quantité d'articles que vous maintenez, pouvez vous vous
>passer d'une base de données (je n'ai pas dit relationnelle) ?
>
>Evidemment je suis bien plus intéressé de découvrir votre solution RSS,
>mais avec notre SDX, ce sont des choses que nous faisons très
>simplement. Je n'ose pas vous le conseiller complètement pour l'instant
>car je ne sais pas encore l'effort que cela représentera de le passer à
>cocoon 2.1. Le principe, par contre, peut vous inspirer.
>
>Cela repose sur Lucene. Tous les documents sont indexés en plein texte,
>avec des champs pour leurs meta (date, sujet, auteur...). Cela devient
>alors très facile de fournir des listes de termes sur un champ, ainsi
>que bien sûr des résultats sur des requêtes.
>
>
Je suis très intéressé par ce que peut apporter SDX (ou ses grands
principes) pour faire des recherches classifiées. D'après ce que j'ai
vu, on peut l'utiliser pour naviguer dans des taxonomies (ou
ontologies?) de façon assez souple.
A propos, Lucene 1.3 est sorti, et dans la discussion suivant l'annonce
sur TSS, on parle d'un moteur de recherche assez monstrueux motorisé par
Lucene (http://www.theserverside.com/home/thread.jsp?thread_id=23043)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 31/12/2003 - 17:02 UTC
webmaster@xmlfr.org
|
