Bonjour, Même si l'urgence nous parait être de sortir une (ou plusieurs) version officielle et non béta de SDX afin de consolider l'outil existant et de rassurer les (nombreux) utilisateurs, il est en effet important d'envisager les évolutions futures de la plate-forme SDX.
Mobydoc comptant déjà beaucoup d'utilisateurs ayants passé du temps à mettre en place un O.P.A.C. basé sur SDX 2, nous sommes enclins à privilégier les solutions qui nécessiteront le moins d'effort de migration. C'est pourquoi tous les outils de conversions visant à faciliter ces futures migrations seront les bienvenus. Ceci dit, entre les 2 options proposées il parait difficile de voir la meilleure sans avoir une idée plus précise de ce que pourra concrètement apporter le fait de ne plus être lié à cocoon 2.1. Pour l'instant, il parait évident qu'un changement de framework provoquera de notre côté plus de travail d'adaptation pour notre outil. Ceci impliquerait donc, à moins d'avoir des précisions supplémentaires, que je pencherais naturellement pour la première option. Cordialement, Vincent Leconte Mobydoc -----Message d'origine----- De : sdx-users-bounces De la part de Jean-Luc ARVERS Envoyé : mercredi 13 mai 2009 10:50 À : [email protected]; [email protected] Objet : [sdx-users] SDX et puis ? 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 _______________________________________________ sdx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sdx-users _______________________________________________ sdx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/sdx-users
