Re: [sdx-developers] COP

[Pierrick Brihaye]

Bonjour,

Nicolas Maisonneuve a écrit:

> y'a des classes qui utilisent des interfaces d'avalon.. mais je n'ai pas vu
> dans vos source , un lookup(moncomposant.role);

Oui, c'est vrai. Cela s'explique par le fait qu'on a une arborescence de 
ce type :

Framework
--Application
----DocumentBase
------Repository

Le Framework est une "application" Cocoon et est d'ailleurs mis à sa 
disposition dans cocoon.xconf. Là où ça coince, c'est que les les 
"sous-composants" n'ont pas a priori à être *globalisés* au niveau de 
Cocoon.

Pour les Repository, assez analogues à des <datasources>, on peut encore 
discuter mais, sur le fond, Cocoon manque encore (à ma connaissance) 
d'un système de "sous-montage" de composants. J'ai par exemple toujours 
trouvé bizarre qu'il faille forcément déclarer les pools de connection 
SQL au niveau global alors que, tout naturellement, ils devraient l'être 
au niveau des applications puisque ce sont elles qui font usage des dits 
pools. Enfin... des pools globaux peuvent aussi exister.

SDX propose une approche "intra-application", certes sans tirer parti de 
l'architecture Avalon ; je reconnais donc qu'elle manque sans doute 
d'élégance :-) Il est cependant bien pratique de pouvoir rapidement 
définir son appli dans un seul fichier car ça, les utilisateurs aiment !

> et ne sont pas traités en tant que composant mais seulement en tant que
> classes ordinaires .. (evidemment on perd tout l'interet  car on a plus la
> gestion du lifecycle  du composant fait par le conteneur, seul avantage d'un
> composant par rapport à une classe ordinaire)

La plupart des life cycles SDX ne sont pas particulièrement difficiles à 
gérer. On aurait pu mieux faire sur la gestion des connections aux 
repositories et des (éléments) de pipeline mais, encore une fois, ça 
pose le problème de savoir qui serait propriétaire de ces composants ; 
il y a là sans doute des pistes à explorer et, en premier lieu, coller 
auatnt que faire se peut au design Avalon/Cocoon.

>  (j'ai l'impression que le package OAI a été fait plus 'esprit composant
> ...)

Oui : raisons historiques. Ce package est plus récent.

> > org.apache.avalon.excalibur.datasource pour les repositories, mais la
> > méthode clé, getConnection() est typée... java.sql.Connection :-(
>
> ha.. j'suis content de cette remarque .. car je voulais aussi utiliser cette
> interface  pour un composant utilisant Xindice 

Bon, et bien on est au moins 2 :-) 3, si on considère une intervenante 
de [sdx-users]. A titre personnel, je lorgne plutôt du côté de eXist ;-)

> (d'ailleurs à quand un
> repositories xmldatabase dans SDX..)

Il tombe sous le sens. Le problème est de savoir comment intégrer ça à 
l'existant ? La dissymétrie SQL/non-SQL est fâcheuse alors que, 
fondamentalement, la logique est la même. On peut se connecter à un 
fournisseur de ressource (DataSource ?) et, avec cette connection, faire 
des ajouts, mises à jour, destructions, requêtes. En SQL, le langage de 
requête, c'est... du SQL, en XMLDB, ça peut être du XPath ou du 
XQuery/XUpdate. Fondamentalement, ça n'en reste pas moins du texte à 
fournir à un Statement retournant des listes de ressources, ordonnées ou 
pas. Plutôt que de partir de java.sql.*, on aurait mieux fait de partir 
d'une UnsupportedQueryLanguageException :-))

Oui, vraiment, je suis supris du manque d'abstraction proposé par Avalon :-(

> d'ailleurs je vais poster un mail sur ce problème sur la mailing list Avalon

Je vous souhaite les meilleures chances de succès !

> > Commentaire personnel : avec ses fichiers de config dispersés ça et là,
> > je ne sais pas si Cocoon est si flexible que ça :-) Enfin... les blocks
> > pourraient considérablement arranger ça...
>
> y'a pas des dizaines de fichiers de config ..

Certes.

> a part cocoon.xconf, lieu de toute la configuration des composants

V. plus haut. IMHO, c'est justement là le problème. Si j'ai envie de 
tester une appli XSL 2.0, j'aurai besoin d'un processeur ad hoc. Pendant 
mes tests, je n'ai pas forcément envie de faire traiter les XSL de mes 
autres applis par un processeur en version bêta ! J'aurais donc aimé 
pouvoir *facilement* disposer d'un processeur au niveau application vs. 
un processeur au niveau global.

M'enfin, les blocks pourront peut-être aider : ils semblent s'orienter 
vers la gestion du versionning... qui n'est qu'un des aspects de la 
question.

> > Petite note sur le transformer : on optimise et on ferme le writer sur
> > le dernier élément <index/> (dernier élément du document d'indexation en
> > fait). Qu'en est-il de la performance ?
>
> pour mon transformer... j'avoue que je n'ai pas spécialement testé les
> performances..

Le problème qui risque de se poser, c'est la croissance exponentielle 
des temps de d'optimisation. Ici, il y a sans doute de l'optimisation 
fonctionnelle à faire : une indexation en mémoire et des merges "à la 
carte" ?

> par contre  je ne comprend ou est le problème dans l'optimisation et la
> fermeture du writer,  y' a til une mauvaise facon de faire ?

Chez Lucene, il y a 2 approches : ceux qui laissent le writer ouvert (en 
l'optimisant de temps en temps) et ceux qui le ferment immédiatement 
après usage (comme vous). Chaque approche a ses avantages et ses 
inconvénients.

Il serait intéressant d'avoir des benchmarks mais je suis plutôt de ceux 
qui pensent que l'indexation peut se permettre de mobiliser des 
ressources pour, en contrepartie, offrir de la performance en recherche. 
Bref, je suis plutôt de votre école :-)

> j'ai  créé ainsi l'analyserManager (inspiré de SDX mais plus simple)

D'autres analyseurs devraient suivre... bientôt ;-)

> un indexbaseManager (un documentBase pour SDX, sans les repositories,
> histoire de séparer un maximum )

Intéressant...

> (le binding sera enlevé
> et mis dans un composant dédié à la transformation d'un XML en
> lucene.document.. )

On en reparle de suite...

>  <fieldList>

Vous avez donc une fieldList *contrainte* ? On en a parlé récemment. Ici 
encore, plusieurs approches sont possibles et... pas contradictoires. 
L'énorme force de Lucene, c'est de ne pas imposer de schéma a priori. 
Allez faire ça avec un SGBD !

>   <documentxml URI="http://www.ecr.org/description/1.0";>
>    <bind xpath="/:description/:ID" idref="INDEXID"/>

Mmmh... plutôt qu'un binding de ce type, ne pensez vous pas qu'un 
fragment XML destiné à alimenter votre transformer serait moins 
fastidieux à mettre en oeuvre ? Le binding XPath est IMHO, l'un des 
principaux défauts d'eXist alors que la génération de document(s) 
d'indexation est, IMHO, la principale qualité de SDX :-)

> je pense aussi faire un writerManager qui gère justement le problème de la
> demande de plusieurs instances de writer pour la meme base index
> et aussi plusieurs composants  pour  le role de XMLtoLucene

Intéressant.

A bientôt,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden