Re: [sdx-developers] Le developpement de SDX

[Pierrick Brihaye]

Salut,

Martin Sevigny a écrit :

> Si l'un ou l'autre d'entre vous ou des institutions que vous représentez
> ont envie de faire l'une ou l'autre de ces interventions au cours de la
> prochaine année ou plus, merci de vous signaler, soit sur cette liste,
> soit à moi directement.

Je ne représente quère que moi-même... allez, mon service. Chacun sait, 
en effet, que je vais changer de tutelle dans les mois qui viennent.

En l'état actuel des choses, la sous-direction de l'Inventaire semble se 
satisfaire de SDX 2.2. Des développements assez ambitieux sont en cours. 
Je me demande cependant si cette version supportera la charge (60.000+ 
documents), en particulier lors de l'indexation : on explose 
régulièrement les descripteurs de fichiers et/ou on tombe sur un 
problème de synchronisation entre IndexWriter/IndexSearcher.

Il faudra donc probablement envisager un passage à la v. 2.3 (et au 
nouveau Lucene) dans l'année... si celle-ci est consolidée.

Pour ma part, j'ai un gros besoin de pipelines dynamiques en destruction 
(v. mes posts récents) de façon à pouvoir intégrer une indexation 
multiple. Je suis prêt à me mettre là-dessus assez vite et, 
éventuellement, sans consentement des autres développeurs :-)

Cependant, je me demande si SDX ne devrait pas être refactorisé de fond 
en comble en particulier dans le but de récupérer autant de composants 
Cocoon que faire se pourra (sources de données, indexeurs...). Dans 
cette logique, SDX consisterait essentiellement en un jeu de sitemaps 
permettant la communication entre composants via des namespaces robustes.

Il va de soi que les très pratiques API-URL doivent perdurer tout en 
faisant usage des parties de sitemap ad hoc plutôt que de coder du Java 
en dur.

Je suis prêt à m'investir pas mal là-dedans, mais il faut auparavant que 
je récupère un accès CVS car, sans cela, ma contribution restera un voeu 
pieu.

Une segmentation claire des fonctionnalités : code, sitemaps, 
logisheets, docs, test cases... permettrait sans doute d'élargir le 
spectre des contributeurs car elle n'imposerait plus une connaissance 
intime du code sous-jacent.

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78