Re: [sdx-developers] COP

[Nicolas Maisonneuve]

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

 

hmm... a chaque fois , j'ai eu des pb d'installation

mais jai pas trop insisté

c'est vrai qu'il est plus riche en fonctionnalité

 

pour le mail a avalon ..j'ai eu une reponse basé sur  le xmldb.api qui propose une interface d'implementation d'une database

que j'ai implementé. au lieu d'avoir un java.sql.connection  , j'ai donc un Collection

qui a la meme fonction.

 

>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.

 

je ne suis pas trop un espert en avalon.. mais je crois qu'il peut y avoir plusieurs composans ayant le meme role (= plusieurs processeurs : un beta , un stable)

d'ou l'interet du selector dans Avalon. Donc rien empeche d'ajouter un processeur stable et de selectionner lorsqu'on n'en a besoin

donc cocoon s'en sort pour ce problème..

 

>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 !

Le fait de ne pas savoir  quels champs existent dans l'index .. meme si certain y voit une liberté mais j'y vois une possibilité d'erreurs, de confusions..etc

disons que je n'ai jamais trop vu l'interet de cette possiblité.. peut être qu'avec un use case bien particulier ok mais là ..

a vrai dire.. j'avais meme fait des methodes pour vérifier que le document qui va être indexé etait valide (tout les champs du documents étaient declarés dans l'index)

comme ca j'étais sûr..

 

-- entre parenthèse -- 

la liberté d'un programme n'est pas toujours une force ,, y'a des libertés bien inutiles , source d'erreurs possibles.. des libertés qui demande à l'utilisateur plus de travail, etc, enfin bon je ne suis pas pour la liberté en general mais seulement pour des libertés bien reflechies .. ou alors des outils d'aide sont a la disposition des utilisateurs

pour faire les taches les plus courantes

-- fin parenthèse --

 

 

>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.

ha  je ne savais pas .. quelles sont les avantage/con des 2 écoles ?

 

 

>   <documentxml URI="http://www.ecr.org/description/1.0">
>    <bind xpath="/:description/:ID" idref="INDEXID"/>
oui le coup du binding et du xmltoLucene .. j'ai changé de stratégie

j'ai fait un indexbaseTransformer et le binding se fait comme dans SDX par une feuille de style

on a donc un binding_manager

<binding_manager>

<binding URI="http://www.ecr.org/description/1.0"  indexbase="componentbase" defaultxsl="/resources/ecr/description.1.xsl" >

<binding URI="http://www.ecr.org/description/1.0"  indexbase="componentbase2" defaultxsl="/resources/ecr/description.12.xsl" >

<binding URI="http://www.ecr.org/description/2.0" indexbase="componentbase" defaultxsl="/resources/ecr/description.2.xsl" >

</binding_manager>

le but c'est qu'avec un outil on prend un schema XML et on demande à l'utilisateur quelle sont les champs qui veut rechercher sur ce type de document

et le xsl est generer et la ligne binding ajouté.. (bien evidamment rien n'empeche de creer son propre xsl et/ou de configurer le binding manuellement)

 

le binding manager pourra être appelé par une cocoon action par exemple , histoire de choisir la bonne feuille de style

Est ce une bonne idée ?

 

voilà , voilà pour l'instant..

 

 

----- Original Message -----

From: "Pierrick Brihaye" <address@hidden>

To: <address@hidden>

Sent: Tuesday, September 02, 2003 10:02 AM

Subject: Re: [sdx-developers] COP

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



_______________________________________________
sdx-developers mailing 
list
address@hidden
http://mail.nongnu.org/mailman/listinfo/sdx-developers