> Desole, cet email etait reste en plan.
Et celui là aussi (je suis très pris ces jours ci). Je vais donc
conclure pour moi sur ce sujet, en souhaitant vous revoir sur un thread
plus frais.
> Ce serait interessant de savoir pourquoi ce feature particulier est si
> important pour vous, au point d'etre un "showstopper".
Nous sommes très exigeants sur les composants que nous utilisons. Pour
vous donner un exemple, j'ai fait ceci
<http://sdx.archivesdefrance.culture.gouv.fr/ecfa/report.xsp>, 1
millions d'actes d'état-civil, et en intranet il y a les pages
numérisées correspondantes (1 Mb chaque). Je regrette maintenant d'avoir
si peu optimisé le code (par ignorance, et je testais avec 2 000). Nous
jouons parfois avec les limites de certains composants, et devons
patcher avec les derniers commits sur le projet. Evidemment, j'imagine
que le rerootage ne concerne que XML et XSL pour Java 1.4, chose ayant
l'air d'être modifiée pour Java 1.5, mais vous comprenez que sur le
principe, ne pas pouvoir librement mettre à jour un composant sur la
distribution officielle, c'est un problème pour des applications que
nous ne voulons plus maintenir, et dont les administrateurs peuvent
avoir des compétences inégales.
> > Cette réactivité vous honore, mais s'il on voit aussi le point du
> > dessus, et bien d'autres qui pourraient surgir de la comparaison,
> > reste à voir si vous avez les moyens de suivre.
>
> Est-ce que Cocoon va suivre ? ;-)
Nous sommes 2, ils sont 1000, encerclons les :o)
Je partage votre enthousiasme offensif, lucene, saxon, une tête peut
suffire à lancer de grands projets.
> Il n'y a aucune garantie de ce
> cote-la non plus, car les developpeurs de Cocoon choisissent en toute
> liberte ce sur quoi ils veulent travailler (par exemple en fonction de
> leurs contrats ou projets personnels) et ne reagissent pas forcement a
> la demande des simples utilisateurs de la plateforme.
Je suis d'accord, pour des questions de poids au téléchargement il m'est
arrivé de sérieusement alléger un cocoon.
> > A moins que de passer dans le libre soit une stratégie de
> > recrutement ?
>
> Bien sur, nous desirons attirer des developpeurs externes, tout en
> etant conscients que notre core team sera le contributeur principal
> pendant longtemps.
Nous avons la même expérience.
> > Orbeon aurez une solution assez commode pour profiter de cette
> > puissance et d'alléger la maintenance de choses résolue ailleurs,
> > implémenter XPL dans cocoon :o) (avant que quelqu'un d'autre ne le
> > fasse).
>
> Nous serions tres heureux de voir d'autres implementations de XPL se
> developper, y compris integrees a Cocoon. Tout pas serieux vers le
> developpement d'un langage de pipelines XML standard, de facto ou de
> jure, serait le bienvenu.
Là, je vous suis entièrement ! J'aimerais pouvoir capitaliser des tuyaux
comme de l'XSL et du JAVA, qui peuvent tourner dans plusieurs contextes.
> > Qui irait voir sous le capot de "Presentation Server" ?
>
> Certains l'ont deja fait. Certaines parties du code sont difficiles a
> comprendre (je suis sur que c'est le cas de certaines parties de
> Cocoon egalement),
J'ai moi aussi commis des boîtes noires "magick code". Je ne veux plus y
mettre le nez, je plains ceux devant maintenir.
> On voit beaucoup de competition dans l'open source, par exemple KDE
> vs. Gnome, Linux vs. *BSD, et dans le monde Java, Eclipse
> vs. NetBeans, plusieurs parseurs XML et transformeurs XSLT,
> application servers (JBoss, JOnAS, bientot Apache Geronimo), sans
> parler des multiples frameworks pour web applications, etc. Il n'est
> pas dit qu'il n'y ait pas de place pour deux plateformes XML Java open
> source.
Vous avez raison, la concurrence est certainement la meilleure manière
de faire avancer et de favoriser l'émergence de standards. De la même
manière qu'Eric Van Der Vlist, on voudrait que la logique d'une
application ne dépende pas de son environnement, comme le texte que
j'écris a autant de valeur sous Word ou oo.
--
Frédéric Glorieux (ingénieur documentaire, AJLSM)
<http://www.ajlsm.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)
Received on Sat Oct 9 10:11:20 2004
