[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sdx-developers] SDX 3 : approche conceptuelle
From: |
Pierrick Brihaye |
Subject: |
Re: [sdx-developers] SDX 3 : approche conceptuelle |
Date: |
Fri, 07 Mar 2003 10:34:35 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.1) Gecko/20020823 Netscape/7.0 |
Salut,
J'en remets une couche ;-)
Pierrick Brihaye a écrit:
Pour les archives :-)
Idem.
En dynamique, on est assez proche du concept de générateurs Cocoon (à
ceci près qu'un générateur sert a priori à lire plutôt qu'à écrire). Ci
après veuillez considérer que les vues dynamiques sont confiées à des
repositories... en mémoire.
Je suis preneur de toute idée qui pourrait mutualiser les 2 approches...
C'est là où je coince encore... probablement à cause de ma faible
connaissance de Cocoon 2 et, surtout, de ma connaissance quasi-nulle sur
les évolutions de Cocoon.
G) Evidemment, on aurait un repository supplémentaire pour stocker les
relations entre vues.
Et un autre... j'y reviens plus bas.
K) la taglib devra proposer des API génériques de gestion du contenu des
repositories. Typiquement, on pourrait avoir des trucs comme ça :
> Note : exemples provocateurs. En fait, on a là de beaux pipelines Cocoon
> n'est-ce pas ?
Commentaire :
pipeline -> <sdx:insert>
générateur -> <sdx:from id="stockage"/>
tranformateur(s) -> <sdx:pipeline src="indexation.xsl"/>
sérialiseur -> <sdx:to id="indexation" />
L) Les fichers de config pourraient ressembler à çà :
Oups ! Copier/coller trop rapide. Vous avez sûrement dû corriger... je
le redonne en l'amendant :
<sdx:application>
<!-- un accès générique pour tous les repositories de l'appli -->
<sdx:access>
<sdx:groups id="users"/>
</sdx:access>
<sdx:storagerepository id="storage" type="JDBC">
<sdx:datasource ds="jdbc:mysql://server/sdx-storage" user="sdx"
pwd="s1d2x3"/>
<sdx:access type="overrides">
<sdx:group id="admins"/>
<sdx:user id="very_special_guest"/>
</sdx:access>
<sdx:storagerepository>
<!-- ;-)) -->
<sdx:indexationrepository id="indexation" type="LUCENE" />
<sdx:resultsrepository id="results" type="MEMORY">
<sdx:access type="extends">
<sdx:anyuser/>
</sdx:access>
</sdx:resultsrepository>
<sdx:resultrepository id="result" type="XMLDB">
<sdx:access type="extends">
<sdx:anyuser/>
</sdx:access>
</sdx:resultrepository>
<sdx:publishingrepository id="publishing" type="FS">
<sdx:access type="extends">
<sdx:anyuser/>
</sdx:access>
</sdx:publishingrepository>
<sdx:relationsrepository id="relations" type="JDBC" />
<!-- voir de suite pour un autre repository -->
</sdx:application>
Les repositories auraient donc impérativement une interface
insert/update/delete.
Idéalement, ils pourraient prendre en entrée un flux non typé et, pour
facilité le traitement des documents XML, des flux typés (SAX, DOM...).
Idem en sortie.
Certains, en particulier le resultsrepository
pourraient bénéficier d'une méhode search...
... et, d'une façon générale, tous ceux qui seront capables d'en
proposer une : JDBC (via SQL), XMLDB (via X-Path).
Pour les autres, on n'aura généralement qu'une seule requête possible,
une requête (~ SELECT de SQL) sur l'id (key de HashTable pour un
repository de type MEMORY p.e.). Un repository CVS pourrait apporter un
peu plus de fonesse là-dedans : version, branche, tag...
Cette approche permet un truc intéressant, c'est que l'on peut se passer
d'une génération d'id par l'utilisateur (ce qui n'empêche pas de
proposer la surcharge du générateur d'id par défaut comme c'est
actuellement le cas). En effet, dès lors que l'on fait le choix d'un
UPDATE, on a déjà une id... que l'on peut confier sans souci à l'INSERT.
Maintenant, voici le dernier repository en date :
<sdx:logrepository id="log" type="JDBC">
<sdx:datasource ds="jdbc:mysql://server/sdx-log" user="sdx"
pwd="s1d2x3"/>
<sdx:access type="restricts">
<sdx:sdx/>
</sdx:access>
</sdx:logrepository>
Ce serait un repository *système* où SDX stockerait les actions
effectuées sur chacun des repositories ; c'est intrinsèquement tabulaire :
YYYY:MM:DD:HH:MM:SS inserted document "xxx" into repository "aaa"
YYYY:MM:DD:HH:MM:SS updated document "yyy" in repository "bbb"
YYYY:MM:DD:HH:MM:SS deleted document "zzz" from repository "ccc"
Avec ça, on peut définir, toujours dans la config, un "TaskManager" qui
génèrerait les documents (indexation, résultat, publication...) quand un
évènement ad hoc a eu lieu dans tel ou tel repository.
On devrait pouvoir configurer le moment de lancement de tel ou tel type
de tâche (entre "at_once" et... "never" :-) et le nombre de tâches à
effectuer (entre "0" :-) et "everything_that_is_doable").
De même, il faudrait prévoir un mécanisme de purge du repository de log
répondant également aux comportements que je viens de décrire. Ici
encore... c'est une tâche.
Dernier point sur lequel je n'ai pas encore d'opinion bien arrêtée :
A partir de quelle classe lancer la recherche ? Depuis
<sdx:indexationrepository> ou bien depuis <sdx:resultrepository> ? Je
penche pour la deuxième solution dans la mesure où le resultrepository
peut lancer des recherches sur plusieurs repositories d'indexation (les
sdx_locations actuelles).
Voilà,
A+
--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden