Frédéric Glorieux wrote:
> > Je ne suis pas certain que le nombre de développeurs dilue la vision.
> > Dans le cas de Cocoon, même s'il n'y a pas de hiérarchie écrite, il y en
> > a une de fait, et la vision est pilotée et entretenue par un petit
> > nombre de personnes, au premier rang desquelles on trouve Stefano
> > Mazzocchi, qui a créé Cocoon il y a 5 ans.
>
>5 ans, déjà... Mais Mazzocchi, il est encore avec vous ?
>
Bien sûr qu'il est avec nous ! Je discute (en privé) très régulièrement
avec lui, et il participe à toutes les discussions de fond sur
cocoon-dev. Par contre il est vrai que le quotidien (bugs, petites
évolutions, etc) l'intéresse moins qu'à l'époque ou le coeur de Cocoon
était en chantier.
>Je remercie
>encore mon employeur de m'avoir mis sur un bon cheval, j'ai encore reçu
>des propositions hier où des compétences cocoon étaient très recherchées.
>
>
Tiens, moi aussi ! C'est peut-être la même ?
> > Le noyau de Cocoon est bien défini et stable, et le nombre de
> > développeurs a plutôt apporté une richesse fonctionnelle avec un nombre
> > important d'implémentations des interfaces de base du noyau. C'est ce
> > qui donne ce côté peut-être un peu fouillis de Cocoon.
>
>Et le passage aux blocs n'est pas vraiment convaincant. Nous avons du y
>renoncer.
>
Le problème des blocs actuels c'est qu'il ne sont pas vraiment des
blocs, mais plutôt des modules de compilation. Mais c'est un problème
sur lequel nous travaillons (notamment avec Stefano) et qui devrait
déboucher prochainement. En tout cas, c'est une chose qui me démange
suffisemment maintenant pour que j'ai envie de commencer à gratter :-)
>Comme sans doute beaucoup, on se compose une servlet avec les
>briques Cocoon (merci, mais il y a des trucs à bien tester qui ne
>doivent tenir la prod que pour leurs auteurs), et on s'énnerve de toutes
>les surcouches qui nous cachent des choses claires et documentées.
>
>Un exemple, la response HTTP. Je crois que c'est Mazzochi le coupable
>avec son désir d'abstraction, mais sous prétexte de CLI on a un
>copié/collé sous un autre nom, désolé, mais pour moi cela s'appelle de
>la mentalité propriétaire.
>
Là, je dois donner une explication. Cette abstraction répond à diver
besoins :
- indépendance par rapport à l'environnement. Il n'y a pas seulement
http, cli mais aussi portlet, sitemap (pour le "cocoon:") et
"background" (utilisé par le scheduler en tâche de fond)
- besoins complémentaires : le montage de sous-sitemap, par exemple,
nécessite d'avoir des infos supplémentaires qui n'existent pas dans la
requête http
- blindage de l'architecture : l'interface Response, par exemple, ne
donne pas accès au stream de sortie, dont la gestion est sous le
contrôle du mécanisme de pipeline. Cette contrainte évite des "abus" ou
bidouilles préjudiciables au bon fonctionnement du système.
Et puis il faut savoir que la requête servlet (la vraie) est toujours
disponible si on en a vraiment besoin, mais que l'utiliser lie fortement
l'application à l'environnement servlet, ce qui peut être très nuisible
à son évolutivité.
>Je ne reconnais pas là la qualité d'aller au
>plus simple d'un certain cocooner qui nous a déjà montré son talent sur
>cette liste (je le dis sincèrement parce que mes propositions pour la
>même chose tenait plutôt de l'Usinagaz).
>
>
Je suis flatté :-)
>Ceci étant, je me suis livré 8 jours de vacances à tenter de me passer
>de Cocoon (ce qui m'a donné l'occasion d'aller voir dans le code de
>Tomcat et de Jetty), euhh... Saine épreuve à laquelle chacun devrait se
>livrer sur ses convictions. J'y ai gagné une bien meilleure connaissance
>de ce qu'il y a déjà, pourquoi prendre dessus quand le dessous suffit ?
>Mais quand j'ai voulu voir les struts et consort... je suis revenu avec
>joie dans mes générateurs.
>
> > Cette dichotomie se retrouve d'ailleurs dans les formations Cocoon que
> > je donne : la majeure partie du message est liée au fonctionnement de ce
> > noyau et des implémentations de base (xslt, xinclude, xsp, forms, etc),
> > puisque c'est ce que les utilisateurs doivent nécessairement maîtriser,
> > et on donne des méthodes de recherche pour "faire son marché" dans le
> > vaste choix des autres implémentations.
>
>
>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). Qui irait
>voir sous le capot de "Presentation Server" ? Je n'ai aucune compétence
>commerciale mais j'ai l'impression que cela vous ouvrirait sur un marché
>beaucoup plus large que de vous positionner contre cocoon, alors qu'à
>terme les produits sont trop comparables pour ne pas devoir merger un
>jour, sans d'ailleurs dire lequel mangerait l'autre. Cela demande je
>suppose des efforts côté cocoon, mais là je n'ai rien à dire.
>
>
Il y a déjà eu des discussions sur les "content-aware pipelines" pour
que les matchers et selecteurs puissent "voir" ce qui passe dans le
pipeline et donc faire du XPath comme c'est le cas dans OPS. On n'est
pas passé à la phase d'implémentation parce que ça ne devait pas être
pas suffisemment indispensable.
Quand à l'aspect commercial, je crains plutôt qu'implémenter OXF sur
Cocoon ne supprime l'aspect particulier d'Orbeon sur le marché des
frameworks XML. Cela a à la fois du bon (il y beaucoup de demande pour
de l'expertise pointue autour de Cocoon) et du moins bon (perte
d'identité spécifique et de maîtrise sur son outil).
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 "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 Fri Oct 1 15:54:48 2004
