[Top][All Lists]
[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.
- Re: [sdx-developers] RE : Utilisation des tables associees, (continued)
- Re: [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/19
- RE : [sdx-developers] RE : Utilisation des tables associees, Martin Sévigny, 2002/06/19
- Re: RE : [sdx-developers] RE : Utilisation des tables associees, Pierrick Brihaye, 2002/06/19
- [sdx-developers] Plusieurs bases, Martin Sévigny, 2002/06/19
- Re: [sdx-developers] Plusieurs bases, Pierrick Brihaye, 2002/06/19
- [sdx-developers] RE : Plusieurs bases, Martin Sévigny, 2002/06/19
- Re: [sdx-developers] RE : Plusieurs bases,
Pierrick Brihaye <=
- [sdx-developers] RE : Plusieurs bases, Martin Sévigny, 2002/06/20
- Re: [sdx-developers] RE : Plusieurs bases, Pierrick Brihaye, 2002/06/20
- [sdx-developers] RE : Plusieurs bases, Martin Sévigny, 2002/06/20
- Re: [sdx-developers] RE : Plusieurs bases, Pierrick Brihaye, 2002/06/20