Re: [sdx-developers] COP

[Nicolas Maisonneuve]

>Oui, on peut faire comme ça, mais ça pose encore et toujours le problème
>du *contexte* dans lequel les composants sont disponibles. Cocoon a
>choisi un contexte global (roles.xconf, avec, éventuellement des rôles
>utilisateur). Il aurait été plus sympa de proposer des contextes locaux
>et donc de se passer de sélecteurs qui imposent une gestion des hints :-)

 

apparement pour le problème des contextes locaux, y'a peut être une solution avec

les parent component manager..
bon je n'ai pas trop étudié le truc mais voilà l'URL

 

http://cocoon.apache.org/2.1/developing/parent-component-manager.html

 

 

une autre question .. vous avez surement utilisés dejà des RDF avec SDX

Avez vous utilisé le block DELI de cocoon, pour la gestion RDF (et OWL : ontologie web language, langage bientot standardisé par W3C qui pourrait vous servir pour rendre votre thesaurus plus ouvert sur d'autre format) avec la lib jena : http://jena.sourceforge.net/

 

voilà quelques infos

 

sinon connaissez vous aussi

Nutch , un gros moteur de recherche fait par Doug Cuttin  (createur de Lucene) Open Source

apparement bien plus complet que lucene

http://www.nutch.org/docs/en/

 

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

From: "Pierrick Brihaye" <address@hidden>

To: <address@hidden>

Sent: Thursday, September 04, 2003 4:12 PM

Subject: Re: [sdx-developers] COP

Wow ! 18 heures pour l'avoir celui-là :-) Bon, eh bien... 
bonjour,

Nicolas Maisonneuve a écrit:

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

Ca m'arrive de m'occuper des fichiers bat mais, 
visiblement, ça 
n'intéresse pas trop les développeurs :-(

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

J'ai vu. Mais... je ne partage 
pas du tout l'approche.

Une java.sql.connection est une *session* (cf. 
http://java.sun.com/j2se/1.4.1/docs/api/java/sql/Connection.html) entre 
un serveur un client. C'est seulement lorsqu'on a 
ouvert cette session 
que l'on peut obtenir des *services* : citons les 
Statement (DDL/DML), 
les transactions et les métadonnées. Dans le package 
SQL, on considère 
que tous ces services sont potentiellement 
disponibles.

Sur une XMLDB, un getCollection est *déjà* un service 
IMHO... qui peut 
d'ailleurs en proposer d'autres (différents langages de 
requête par 
exemple).

Sur la doctrine, ça me gêne : on n'est pas 
encore entré qu'on demande 
déjà quelque chose :-) Je suis en particulier 
carrément surpris par les 
exceptions que peut lancer getCollection 
(http://www.xmldb.org/xapi/api/org/xmldb/api/DatabaseManager.html#getCollection(java.lang.String)). 


Brrrr... dans ce système, une exception de 
timeout relance une autre 
exception (qui, par définition, doit être 
exceptionnelle) et null prend 
une sémantique... bizarre (collection 
inexistante sur connection réussie :-)

Bref, entre l'approche 
ultra-concrète de SQL et l'approche 
concrèto-abstracto-ratée de XMLDB, il y 
a du boulot ! Mais bon... il 
paraît que le comité XMLDB recherhe des 
volontaires :-)

Moi j'aurais bien vu :

DriverManager -> 
Connection -> 
Service
                                        
-> 
DDL
                                        
-> 
DML
                                        
-> Transactions

commun à SQL et à XMLDB, voire à du WEBDAV, du CVS, du 
FileSystem...

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

Oui, on peut faire 
comme ça, mais ça pose encore et toujours le problème 
du *contexte* dans 
lequel les composants sont disponibles. Cocoon a 
choisi un contexte global 
(roles.xconf, avec, éventuellement des rôles 
utilisateur). Il aurait été 
plus sympa de proposer des contextes locaux 
et donc de se passer de 
sélecteurs qui imposent une gestion des hints :-)

> 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

Tout dépend de l'utilisateur : en développement, je 
serais bien content 
d'avoir une fieldList non contrainte car, je peux 
décider à tel ou tel 
moment d'ajouter un champ (j'en ai une floppée). Au 
déploiement, on 
pourrait effectivement contraindre.

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

Le gros goulot 
d'étranglement, c'est l'ouverture (beaucoup) et la 
fermeture (un peu) des 
IndexWriter/Reader, étant entendu que les 2 
doivent être 
synchronisés.

Si on laisse ouvert, on va avoir de la performance 
d'indexation (si le 
système de fichiers suit bien) mais on va y perdre en 
optimisation ce 
qui, à terme, fera chuter la performance de recherche... 
sans compter 
les éventuels problèmes du côté du système de 
fichiers.

Si on ferme à chaque fois, on répartit certes la perte de 
performance 
dans le temps mais, gloablement, on en perd plus à cause des 
optimisations plus fréquentes...

En fait, il faudrait pouvoir 
disposer des 2 approches. La première se 
ferait dans un contexte où les 
ressources d'un serveur seraient en 
grande partie mobilisées pour 
l'indexation, quitte à jeter des clients. 
La deuxième serait plus dédiée au 
confort des clients avec cet aspect 
mesquin qui fait que ce sont eux qui 
payent collectivement pour la perte 
de performance :-)

On peut aussi 
envisager une approche mixte avec des index en mémoire 
qui, une fois de 
temps en temps (selon le nombre de documents, 
l'occupation mémoire, la durée 
d'existence) seraient fusionnés avec 
l'index sur disque ; si les index 
mémoire sont au préalable optimisés - 
ce qui ne devrait pas être trop 
handicapant -, le processus devrait être 
assez rapide. Tout le problème est 
de savoir si ces index "en transit" 
doivent ou non être disponibles pour la 
recherche. A titre personnel, ça 
ne ma paraît pas nécessaire : le client a 
attendu des années que le 
document soit accessible ; il peut bien attendre 
encore un peu :-)

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

A vue de nez, c'est bon. Ce type de 
composant pourrait tout à fait être 
utilisé (lookup ;-) par une DocumentBase 
SDX.

[snip ~50 lignes]

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