sdx-developers
[Top][All Lists]
Advanced

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

[sdx-developers] RE : Plusieurs bases


From: Martin Sévigny
Subject: [sdx-developers] RE : Plusieurs bases
Date: Thu, 20 Jun 2002 12:46:21 +0200

Bonjour,

> Petite mise au point : j'ai toujours clamé que SDX n'avait 
> potentiellement aucune limite. Au vu de SDX 2, je le 
> réaffirme haut et fort :-)

Bien sûr, pas de limites, encore faut-il que les choses simples et
fréquentes soient simples à implanter. C'est plutôt là que se situe la
discussion.

> 1) On a du bas-niveau et du haut-niveau. J'entends par 
> bas-niveau tout ce qui stocke de la donnée. Ca concerne les 
> documents, les documents attachés, mais aussi les métadonnées 
> (système ou non) et les index. Le reste est en haut-niveau. 
> Ca concerne le framework, l'appli, les bases, * et donc,dans 
> le schéma actuel, les index, que je viens de définir comme 
> étant de bas-niveau *, les xsl d'indexation ou d'affichage... 
> et SDX lui-même. Note : les fichiers de config sont mixtes 
> dans cette approche selon qu'ils concernent le haut ou le 
> bas-niveau :-)
> 2) Pour moi, le bas-niveau doit être administrable par un 
> technicien réseau. Il est responsable de ses systèmes de 
> fichiers, des passerelles, des droits d'accès, des 
> architectures à mettre en place... Le haut-niveau est, lui, 
> du ressort d'une "autorité morale" telle que tu viens de la 
> définir et sur laquelle je reviens de suite.

Difficile à distinguer ces deux niveaux. Si un concepteur d'applicaiton
décide d'utiliser un entrepôt JDBC, cela a des impacts sur les logiciels
installés, sur des fichiers à gauche et à droite, etc.

> Donc problème : peut-on exposer le bas-niveau sans 
> nécessairement passer par un haut-niveau canonique avec 
> framework, application et tout le toutim ? Je précise tout de 
> suite que je verrais plutôt ça dans SDX 4 :-)

C'est déjà exposé (via les API), maintenant que veux-tu dire par sans
passer par un framework ou appli? Tu voudrais qu'un index (par exemple)
existe sans qu'il y ait d'application ou de framework? Difficile à
imaginer, surtout pour le framework.

Par exemple, si je fais framework.getApplication("un
id").getDocumentBase("un id").getLuceneIndex(), j'ai accès directement à
l'index, via SDX ou directement avec les API Lucene. Cet appel, je peux
le faire depuis n'importe quel code Java, qu'il soit dans une
application SDX ou non, en autant que j'aie accès au framework bien
sûr...

> On est d'accord. On pourrait extrapoler à une recherche sur 
> plusieurs frameworks ?

Oui, c'est prévu (mais non implanté). La semaine prochaine, la taglib
permettra de spécifier, pour les recherches et les listes de termes, un
paramètre "location" qui sera sous la forme appId#dbId, où appId
(optionnel, si non spécifié on suppose l'application appelante) est
l'identifiant public d'une application et dbId (optionnel aussi, si non
spécifié c'est la base de documents par défaut) est le code de la base
de documents à chercher.

Par la suite, on pourra y ajouter une troisième information qui
localisera le framework, sous la forme d'une URL ou quelque chose du
genre, ça dépendra des technologies exactes utilisées pour la recherche
distante. Au total, on pourrait imaginer quelque chose comme:

http://sdx.culture.fr/fr.gouv.culture.sdx.sdxworld#docs

> > Pourquoi ton concept de base générique serait plus intéressant ici?
> 
> Parce que :
> 1) il est plus facile d'ajouter 3 lignes dans un fichier de 
> config que d'écrire une XSP de dispatching vers telle ou telle base 

Pour des requêtes? Ce serait ainsi par exemple:

<sdx:executeSimpleQuery locationParam="l"/>

Où le paramètre d'URL 'l' (répétable) contient une localisation sous la
forme discutée ci-dessus. On peut évidemment le coder en dur ou le
prendre d'une variable.

> 2) comme tu le disais, il est beaucoup plus délicat d'assurer 
> la cohérence de bases différentes dont la seule justification 
> de leur différence est une indexation multiple

C'est certain. Donc en ayant une base à plusieurs index on évite cela...
Ouais...

> 3) ça permet de disposer d'un accès à des bases dont on 
> ignore totalement l'architecture sous-jacente

Je ne vois pas en quoi c'est différent à ce niveau. Dans l'architecture
actuelle c'est pareil.

> 4) ça permet de n'exposer certains index qu'à telle ou telle 
> appli, tel ou tel framework, tel ou tel utilisateur... 
> Intéressant en phase de test ou pour bloquer les accès. Pour 
> illustrer mon propos : http://sdx.culture.fr/sdx/servlets/users

C'est aussi prévu, du moins au niveau de l'application, pourquoi pas au
niveau des bases.

> Ceci dit, j'admets (haut et fort ;-) que rien de ce que je 
> viens de dire n'est impossible dans SDX 2, fût-il en version 
> de développement... Je compte même le prouver bientôt :-)

Je sais, on cherche plutôt à savoir ce qui est plus simple et plus
élégant.

> >J'ai assez réfléchi à ce problème, et j'avoue que j'ai 
> toujours pensé le
> >régler au moment de la requête. Mais peut-être qu'il y a des 
> choses que
> >je ne vois pas.
> 
> Donc, tu optes pour mon approche "pseudo-multilinguisme" ? Et 
> ceci, avec une seule indexation ?

Si on veut, oui.

> Comment ferais-tu pour, disons, consulter de la documentation 
> multilingue ? Disons... la traduc de la doc SDX commencée en 
> français et partiellement traduite en anglais ou, plus 
> vicieux, *doublonnée* en français ? Ce n'est pas une 
> quelconque suspicion, c'est une question... réellement :-)

Oui, je sais que c'est réel. Si j'ai un doc en anglais, je remplis des
champs d'indexation que j'ai prévus en anglais. Idem en français. En
requête, je cherche dans les bons champs, quitte à dynamiquement
spécifier un champ par défaut.

Si ce n'est pas suffisant, on pourra implanter une notion d'équivalence
de champ pour automatiquement choisir un bon champ en fonction d'une
langue. Un peu de cuisine interne mais ce n'est pas impossible.

Il y a aussi potentiellement une notion d'équivalence de documents, mais
ce sera pour plus tard.

> On est d'accord. Mais c'est parce qu'on a toujours fonctionné 
> comme ça. Moi, ce que j'aimerais, c'est travailler en 
> distribué. Chacun monte son appli ou va la chercher dans un 
> "pool" d'applis, chacun interroge préférentiellement son 
> appli mais rien n'empêche de balancer les requêtes sur les 
> appli des voisins. Si elles renvoient des résultats, tant 
> mieux, sinon tant pis. 

C'est exactement le scénario envisagé par l'architecture actuelle.

> En pratique, ça serait quand même plus 
> compliqué que ça : il faudrait idéalement que chaque appli 
> expose ses métadonnées et que les dispatcheurs de requêtes 
> vérifient d'abord qu'ils sont capables de les exploiter afin 
> de ne pas s'attribuer inutilement de la ressource. 

Framework.getApplication("un id").getDocumentBase("un
id").toSAX(ContentHandler) fournira cette information. Est-ce que SDX
lui-même va l'exploiter? Je ne sais pas, peut-être pas à court terme,
mais au moins ce sera disponible.

> Bon. Revenons au présent : j'ai vu les récents commits et 
> j'ai apprécié. Si ça vous ne dérange pas, je prendrai les 
> fichiers ce WE histoire de revoir la documentation. Ca me 
> permettra d'avoir du javadoc propre et de faire une liste de 
> TODO que je vous exposerai.

Ben fais attention, j'ai mis du code de type virus puor empêcher les
gens de travailler le WE. Quand tu ouvriras un fichier source, tu auras
une fenêtre qui s'ouvrira et qui dira "Il fait beau, ce serait
préférable d'aller à la plage". Si tu ne trouves pas le truc pour le
désactiver, viens me voir... À la plage ;-)

Sans blague, tu fais ce que tu veux, on est prudent sur les commit, on
vérifie juste avant de les faire.

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]