Re: [sdx-developers] SDX 3 : approche conceptuelle

[Pierrick Brihaye]

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