sdx-developers
[Top][All Lists]
Advanced

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

[sdx-developers] SDX et puis ?


From: Jean-Luc ARVERS
Subject: [sdx-developers] SDX et puis ?
Date: Wed, 13 May 2009 10:49:32 +0200
User-agent: Microsoft-Entourage/12.17.0.090302

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]