sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [sdx-users] SDX et puis ?


From: Emmanuel Bégué
Subject: RE: [sdx-users] SDX et puis ?
Date: Tue, 26 May 2009 19:28:31 +0200

Bonjour,

Si j'ai bien compris la proposition principale, il s'agit de développer
un "SDX 3" qui serait une sur-couche de Solr.

La question qui nous est posée est de savoir s'il est préférable d'associer
à cette sur-couche Cocoon 2.1, pour continuer à pouvoir développer en XSP,
ou si on abandonne complètement Cocoon et XSP pour JSP, ce qui impliquerait
alors que:
- les développements complémentaires futurs aux applications SDX seront
  effectués en JSP,
- les développements complémentaires existants, en XSP, seront incompatibles
  avec SDX 3, sauf à disposer d'un compilateur ad hoc XSP2JSP.

Ce qu'on doit d'abord souligner c'est la stabilité de la version actuelle
de SDX (pourtant toujours "beta").

Ce produit est "mature", comme on dit, et a fait ses preuves; on peut donc
toujours l'utiliser, et ceux qui voudraient continuer à travailler avec
XSP peuvent s'appuyer sur la version actuelle (surtout si elle est
finalisée comme annoncé, avec la possibilité d'utiliser XSLT 2.0 -- mais
même sans ce complément, ça marche très bien).

C'est pourquoi je ne crois pas qu'il soit intéressant de vouloir rester à
toute force rétro-compatible avec XSP, ni en se lançant dans la réalisation
d'un compilateur XSP2JSP, qui sera nécessairement très complexe et qui 
mobilisera
des ressources qui ne pourront pas être consacrées à autre chose, ni en créant
une couche XSP spécifique dans SDX 3 (ce qui reviendrait d'ailleurs au même),
ni même en récupérant Cocoon 2.1, ce qui serait peut-être un peu moins compliqué
à court terme (voire?) mais certainement plus compliqué et plus lourd à long
terme.

C'est pourquoi je penche pour la deuxième solution, définie comme suit:
1. SDX 2.4: XSP et XSLT 2.0 (et une version récente de Lucene)
2. SDX 3: Solr + SDX (contenu à définir?) + JSP

ce qui me semble être le mieux à même de satisfaire les besoins présents,
et futurs...?

Cordialement,
Emmanuel Bégué


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of Jean-Luc ARVERS
> Sent: Wednesday, May 13, 2009 10:50 AM
> 
> Bonjour,
> 
> Un grand merci à toutes celles et ceux qui ont nous fait connaître ces
> belles utilisations de SDX.
> 
> Nous en connaissons beaucoup plus, mais tous les utilisateurs ou
> développeurs ne sont pas abonné à cette liste.
> 
> La discussion que nous lançons ici est un peu technique, et 
> veuillez nous en excuser. Cependant, nous devons l'aborder avec
> vous pour savoir ce que les uns et les autres attendent de SDX.
>  
> Les récentes orientations de Cocoon, sur lequel est basé SDX, 
> nous ont tous "interpellé". 
> Comme beaucoup le savent, les dernières évolutions de Cocoon  
> (Cocoon 2.2 et plus) ne supportent plus XSP.
> ( http://www.nongnu.org/sdx/docs/html/doc-sdx2/fr/reference/xsp.html )
> 
> SDX est aujourd'hui basé sur Cocoon 2.1 . Même si elle est 
> maintenue, cette version de Cocoon ne connaîtra plus d'évolution.
> 
> Essayer de "coller" aux évolution de Cocoon (2.2 et 3) suppose soit de
> changer de langage (abandon de XSP pour flowscript ou JSP, ...) ou de
> développer et maintenir le support de XSP pour Cocoon 2.2. Ce 
> dernier point n'est pas envisageable.
> 
> Aujourd'hui, SDX est entièrement fonctionnel.
> 
> Cependant il est légitime de chercher à bénéficier des évolutions du
> framework et de Lucene. Dans notre cas, il faut revoir le gestionnaire de
> framework, et...
> 
> Nous devons donc parler de l'évolution de SDX.
> 
> Selon les intérêts des uns et des autres, voici ce qui pourrait être
> envisagé. 
> 
> 1 - Se baser sur le projet Solr pour, entre autre, profiter en permanence
> des dernières évolutions importantes de Lucene,
> 
> 2 - Prendre le "meilleur" de SDX (qui manque dans Solr et dans Lucene:
> couche XML, entrepôt de documents, interface OAI, ...) et l'interfacer a
> Solr.
> 
> Ensuite deux options :
> 
> 1 - Faire une évolution Solr + couche SDX + Cocoon 2.1 (beaucoup des
> développeurs SDX ont besoin de travailler avec les XSP, il faut leur
> permettre de pouvoir continuer à travailler)
> 
> 2 - Faire une évolution Solr + couche SDX + JSP et se rendre 
> indépendant du framework JAVA utilisé
> 
> Enfin, une possibilité si le besoin s'en fait sentir :
> - Permettre la migration des applications SDX 2 vers SDX 3 en mettant à
> disposition un outil de "conversion" des XSP vers JSP et ainsi, valoriser
> l'investissement initial.
> 
> Qu'en pensez vous ?
> 
> -- 
> Jean-Luc ARVERS
> AJLSM
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]