RE: [sdx-users] Travaux de developpement sur SDX

[Emmanuel Bégué]

Bonjour,

Merci de ce message et de cette nouvelle.

Puisque des suggestions sont demandées, en voici quelques unes:

- au niveau "robustesse" et "indexation": nous utilisons SDX sur
une configuration où trois machines Tomcat vont lire un jeu de
fichiers uniques (index et bases hsql):

        . au niveau des bases hsql, elles sont accédées aujourd'hui
        apparemment en écriture même pour une simple consultation
        des résultats de recherche, ce qui fait que la première
        machine qui accède aux fichiers hsql s'en réserve l'accès,
        de telle sorte que la consultation n'est plus possible depuis
        l'une ou l'autre machine (problème contourné par le recours
        à mysql en remplacement des fichiers hsql);
        => il serait intéressant de pouvoir accéder aux fichiers
        hsql depuis n'importe quelle machine (en lecture seule?)

        . au niveau des fichiers d'index, lorsqu'on lance une
        indexation sur une machine (qui modifie donc le jeu unique
        de fichiers partagé par les trois machines), les fichiers
        d'index ne sont plus accessibles par les autres machines
        et on obtient l'erreur "stale nfs file handle"; aujourd'hui
        on reboote donc tous les tomcat après chaque indexation
        => il serait intéressant de pouvoir indexer sans rebooter (?)

- au niveau de l'indexation proprement dite, dans le cas de l'indexation
d'un répertoire, il serait intéressant que SDX puisse de lui-même parcourir
une arborescence de répertoires (c'est à dire que selon un paramètre qui
pourrait être subdir="true", il indexe le contenu des répertoires sous
le répertoire fourni) plutôt qu'on doive lui soumettre chaque
répertoire l'un après l'autre (c'est peut-être déjà possible d'ailleurs?)

- toujours à propos de l'indexation, il serait également très intéressant
qu'on puisse calculer dans la xsl d'indexation un paramètre qui serait
comparé à la valeur d'un champ pour ce document, si un document de même
identifiant est déjà présent dans l'index; le nouveau document ne serait
indexé que si cette valeur est différente/supérieure à la valeur indexée
(=> première utilité: n'indexer que les documents dont la date de mise
à jour est supérieure à la date d'indexation, cad qui ont été modifiés
depuis la précédente indexation -- comparaison avec sdxmoddate; mais on
peut en imaginer d'autres)  -- c'est peut-être aussi déjà possible?
pardon si j'enfonce des portes ouvertes ;-)

- au niveau Lucene, on lit dans la liste des changements récents que
depuis la version 1.4RC1 (point 5):
        Added support for hit sorting. Results may now be sorted by
        any indexed field. (Tim Jones via Cutting)
(cf.
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-lucene/CHANGES.txt?rev=
1.85)

"any" est peut-être beaucoup dire puisque dans le javadoc correspondant
http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/search/Sort.html
on lit "The fields used to determine sort order must be carefully chosen.
Documents must contain a single term in such a field, and the value of
the term should indicate the document's relative position in a given
sort order" mais c'est une demande récurrente des utilisateurs de pouvoir
retourner les résultats triés par date par exemple, quel que soit leur
nombre, sans avoir à effectuer ce tri "a posteriori" (en triant en mémoire
le jeu de résultats => même si c'est fait systématiquement, c'est
impossible sur un très grand nombre de résultats).

- au niveau fonctionnel, il serait effectivement très intéressant pour
un utilisateur identifié de pouvoir sauvegarder un "panier de recherche",
cad ou bien les résultats d'une ou de plusieurs recherches, ou bien peut-
être plus simplement la requête, ce qui prendrait moins de place et
pourrait permettre de la mener à nouveau (si le corpus évolue par
exemple); il serait intéressant aussi que le développeur d'applications
ait un moyen simple d'accéder au texte de cette requête (par exemple
pour pouvoir la mener en batch à intervalles réguliers).

Mais quoi qu'il en soit, SDX est (déjà) une très belle application! et je
profite de ce message pour remercier AJLSM de lui avoir permis d'exister!...

Cdt,
EB


> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden
> De la part de Martin Sevigny
> Envoyé : mardi 18 mai 2004 10:25
> À : address@hidden
> Objet : [sdx-users] Travaux de developpement sur SDX
>
>
> Bonjour,
>
> Au cours des mois de juin, juillet et août 2004, la société AJLSM va
> investir du temps significatif à l'évolution de la plate-forme SDX. Cela
> devrait aboutir sur une version améliorée en septembre 2004.
>
> Je ne peux pas vous donner immédiatement une liste précise des
> développements qui seront effectués, seulement vous en donner les
> grandes lignes.
>
> Le potentiel d'amélioration de SDX est, vous le savez tous, très grand.
> Nous avons des idées pour en faire beaucoup plus que ce que nous
> pourrons effectivement réaliser, et je suis certain que si on y ajoute
> vos idées et vos demandes cela en fera encore plus. Nous devrons donc
> faire des choix et, je ne le vous cache pas, le premier critère sera
> bien sûr de conserver "l'intégrité fonctionnelle de SDX" mais le
> deuxième sera fonction de nos propres priorités par rapport à notre
> utilisation actuelle et future de la plate-forme.
>
> Ces priorités sont pour l'instant à deux niveaux:
>
> 1) améliorer sensiblement la "robustesse" de l'application, en
> particulier sur des points tels que :
>
> - mieux diagnostiquer des problèmes de configuration
> - mieux récupérer de situations anormales
> - mieux répartir les différentes tâches (indexation, recherche, OAI, ...)
> - mieux gérer les différentes données internes à SDX (index, documents,
> relations, ...)
> - faciliter les prises de copies de sauvegarde
>
> Bref, tout ceci ne mènera à aucune nouvelle fonctionnalité
> "utilisateur", mais une plate-forme plus facile à déployer et maintenir
> dans des environnements "complexes" (grandes bases de documents, nombreux
> utilisateurs, ...).
>
> 2) ajouter un certain nombre de fonctionnalités "mineures"
>
> Nous avons un certain nombre de besoins de fonctionnalités "légères",
> c'est-à-dire qui ne remettent pas en cause l'architecture actuelle.
> Parmi ces besoins, notons :
>
> - statistiques d'utilisation
> - mieux exploiter certaines caractéristiques de Lucene, notamment le
> poids des champs ou documents pour le calcul de pertinence
> - paniers / historiques
>
> Je précise que nous ne nous engageons pas (pour l'instant) sur aucune
> fonctionnalité, pas mêmes ces trois idées.
>
>
> A partir de maintenant, je vous invite à faire part, sur sdx-users, de
> vos remarques sur ce message ou d'autres fonctionnalités que vous
> souhaiteriez avoir. Nous ne promettons rien, mais de bonnes idées bien
> argumentées pourraient aboutir. Nous ne commenterons pas tout ce qui
> sera mentionné, mais nous allons tout lire.
>
> Je vous invite toutefois à garder ces discussions au niveau
> "fonctionnel". Si les détails d'implémentation ou si des aspects plus
> techniques vous intéressent et doivent être discutés, je vous invite à
> échanger sur la liste sdx-developers.
>
> Nous allons effectuer ces changements le plus ouvertement possible, et
> de manière à perturber le moins possible les applications bâties sur une
> version 2.x de SDX. Encore une fois, les discussions "au quotidien"
> seront sur sdx-developers, mais nous tiendrons les abonnés de sdx-users
> informés des principales modifications une fois qu'elles seront
> implémentées ou planifiées précisément.
>
> Au plaisr de lire vos réactions,
>
> Martin Sévigny
> AJLSM
>
>
>
>
>
> _______________________________________________
> sdx-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/sdx-users
>