sdx-developers
[Top][All Lists]
Advanced

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

Re: [sdx-developers] RE : Plusieurs bases


From: Pierrick Brihaye
Subject: Re: [sdx-developers] RE : Plusieurs bases
Date: Wed, 19 Jun 2002 19:47:42 +0200

Re,

De la maison et après avoir mangé ; ça devrait aller mieux :-)

>Bon, je pensais que l'architecture était souple, mais c'était sans
>compter les besoins de l'Inventaire!

Je te rassure tout de suite. Ce sont les besoins (potentiels) du félé de 
l'Inventaire ; l'Inventaire, se contentera, je pense, du schéma de bases, 
réparties ou non, que tu (et je) décrivais :-) On en reparlera...

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 :-)

>Je te corrige : si tu parles de 22 serveurs, alors tu parles
>nécessairement de 22 applications SDX, et même 22 frameworks. Pas de 22
>bases au sein d'une même application.

Hé, hé. La mise au point a son importance :-)

J'attrape la balle au bon pour expliciter comment *je* vois les choses :

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.

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 :-)

>Oui, mais une précision : l'interrogation multibase sur Lucene
>fonctionne de façon transparente d'une application à l'autre. Tu pourras
>faire une recherche sur 4 bases provenant de 3 applications par exemple.
>La seule contrainte, c'est que tu connaisses les identifiants publics
>des applications, et les identifiants des bases (si tu ne connais pas
>ces derniers ce sera la base par défaut).

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

> Une application générique peut aussi le faire. 

On est d'accord. Voir mon commentaire sur "SDX peut tout faire".

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

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 :-)

>En fait, je réalise que utilises un critère qui a été ignoré jusqu'à
>maintenant : le développement d'applications SDX par différentes
>institutions (SRI, SSII) qui n'ont pas forcément les mêmes intérêts.
>J'avais toujours imaginé qu'on pouvait considérer une application comme
>étant sous une même "autorité morale".

Je suis assez d'accord avec toi mais, si l'application est répartie ou 
distribuée, on fait entrer un plus ou moins grand nombre de partenaires pas 
toujours disposés, volontairement ou non, à aller dans le même sens et, 
surtout, à la même vitesse. C'est dans cette optique que je perçois une 
opposition plus que potentielle entre haut-niveau et bas-niveau.

>> Sans aller jusqu'à une traduction simultanée des documents à 
>> indexer, on 
>> pourrait utiliser des dictionnaires pour traduire les index dont le 
>> nombre de valeurs est plus ou moins clos : SCLE = "19e 
>> siècle" vs SCLE 
>> (multilinguisme "vrai") = "19e siècle/19th century" vs CENTURY 
>> ("pseudo-mutilinguisme") = "19th century".

>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 ?
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 :-)

>> Pas forcément. Je pense plutôt à :
>> 
>> - *un* framework : bases du MCC
>> -- *une* appli : Inventaire
>> --- *des* bases : dossiers/documents (éventuellement en 22 
>> exemplaires)
>> ---- *des* repositories : XML CI, XML Docbook, images, fonds 
>> de carte...

>Hormis la question de l'autorité morale de l'application (et de tout ce
>qu'il y a en-dessous), c'est le schéma SDX 2 que tu décris.

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. 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. Mais bon, ce protocole est une problématique qui 
va largement au-delà du cadre de SDX.

>Bien sûr. Et tant mieux. Pour STRABON, par exemple, les frameworks
>seront dans les pays méditerrannéens, alors ça s'arrangera peut-être
>moins vite!

Connaissant le problème, ce n'est pas moi qui vait te contredire. J'ai bien 
peur que là, l'architecture ni-répartie ni-distribuée s'impose de fait :-)

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.

p.b.



reply via email to

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