Re: [sdx-developers] COP

[Pierrick Brihaye]

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