Re: [sdx-developers] SDX 2.2 : suggestions d'ajouts mineurs

[Pierrick Brihaye]

Salut,

Martin Sevigny a écrit:

> - indexation avec fragmentation
>
> Lorsqu'on indexe des documents fragmentés, on n'a une mauvaise
> information concernant le nombre de documents indexés (toujours 1), même
> si tous les sous-documents sont listés. La sortie de l'indexation
> pourrait être améliorée.

+1

> - indexation avec documents attachés
>
> Il pourrait être intéressant d'avoir des informations sur les documents
> attachés lorsqu'on indexe, leur liste ou le nombre, selon les paramètres
> spécifiés.

+1. Peut-on aller jusqu'au type MIME ? à la longueur de contenu ?

> - messages d'indexation
>
> Il pourrait être intéressant de supporter un élément <sdx:message> dans
> le document d'indexation (sortie d'un pipeline d'indexation) qui
> permettrait à SDX de logger ce message mais aussi de le retourner dans
> les sdx:uploadDocument.

+1. C'est Pierre Dittgen qui avait lancé l'idée et j'avais proposé une 
piste de résolution. Cependant, ça me pose un problème de design de code 
: est-ce que la gestion de l'indexation doit se faire dans les classes 
du package fr.gouv.culture.sdx.document ? Pour moi, on devrait essayer 
de faire ça dans un truc comme :

fr.gouv.culture.sdx.search.indexing (et 
fr.gouv.culture.sdx.search.lucene.indexing)

... et, au moins à terme, "Avaloniser" le package document pour lequel 
le taux de recouvrement me semble a priori important.

> - fieldlist réutilisables
>
> Dans application.xconf, permettre de définir des <sdx:fieldList id=""/>
> au niveau de l'application ou de la base de documents et y faire
> référence dans une (autre) base de documents : <sdx:fieldList ref=""/>,
> afin de permettre la constitution de multiples bases de documents
> partageant la même structure.

+1. J'aimerais aussi la possibilité de *ne pas* définir de fieldlists 
ou, en clair, d'avoir des FieldList dynamiques (réservées aux 
utilisateurs avertis). Je ne sais pas ce que vous en pensez, mais un 
moissonneur utilise a priori de telles FieldLists, non ?

> - sdx:userIsAdminOrMember dans la taglib

+1. A ce propos, ne serait-il pas intéressant de développer des actions 
Cocoon pour ceux qui veulent gérer ça en Sitemap ? La taglib pourrait 
efficacement en faire usage.

> - permettre de définir des groupes et des utilisateurs dans le .xconf
> (généraliser sdx:admin?)

+1. Et avoir la possibilité de définir un chemin vers un fichier externe 
d'utilisateurs ? Même chose d'ailleurs pour le fichier de config de base 
: ça éviterait, au démarrage d'une appli SDX "packagée" d'avoir à 
définir un SU.

> - lastModificationDate() dans DocumentBase pour faciliter la gestion des
> caches

+1

> - trier les sdx:terms (sur le nombre de documents par exemple)

Vu la discussion à ce sujet... j'hésite encore sur la pertinence de ce 
tri "partiel", mais bon... pourquoi pas ?

> - exploiter [Lucene]Document.setBoost() et [Lucene]Field.setBoost() au
> moment de l'indexation

+1.

> - intégrer ceci http://sourceforge.net/projects/normalizer/ ?

Pas encore regardé en détail mais ça me fait penser à une autre question :

J'ai vu que SDX avait intégré les versions récentes de Lucene. Est-ce 
que le highlighter fonctionne encore avec ce code ? Si oui, je vous 
propose de vous envoyer un analyseur arabe assez performant (ça explique 
mon silence du mois dernier ;-) : il ne reste "plus" qu'à le greffer sur 
Lucene, ce qui, en matière de codage devrait se limiter à une 
utilisation judicieuse de PositionIncrement lors de la fourniture des 
tokens.

Autre chose sur le développement : je ne sais pas quel encodage utilise 
votre éditeur Java : ça n'a pas l'air d'être de l'UTF si bien que les 
accents des commentaires en français (venus de SDX 1) on du mal à passer.

A très bientôt,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden