Re: RE : RE : [sdx-users] qid=q0 :-(

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> OK, tu veux dire que deux exécutions de la même XSLT ne donnent pas la
> même session?

Ben... a priori, aucune n'est capable de garder/transmettre un 
identifiant ce qui, en clair, veut dire un nouvel identifiant pour 
chaque appel à document().

Il n'est pas impossible que des processeurs comme Saxon aient un 
mécanisme de contrôle des headers HTTP mais comme je pense que c'est au 
serveur de gérer ça, je ne suis pas allé plus avant.

> La cache serveur est la seule solution alors, mais on est très loin de
> cela...

Mmmh... de but en blanc, il "suffirait" que :

1) dans AbstractQuery, au lieu de :

results.setUp(searchLocations, searchHits, sortSpecification, this);
return results;

On ait :

results.setUp(searchLocations, searchHits, sortSpecification, this);
//retourne l'identifiant du jeu de résultat
return this.framework.storeResultsAndGetAnIDForThem(results)

2) qu'on ait une un truc du genre /sdx/api-url/getResults.xsp?qid=xxx (à 
inclure dans une action de sécurité ;-) C'est naturellement ça qui 
serait utilisé par les document() des XSL.

3) que l'on décharge la taglib de la numérotation des jeux de résultats 
(qui est d'ailleurs une faille de sécurité IMHO).

Le truc en plus, c'est de vider la hashTable dans laquelle seraient 
stockés les résultats. Dans un premier temps, on pourrait singer ce qui 
se passe dans la taglib, à savoir pas plus de N résultats par session. 
Le ménage serait fait quand on stocke des résultats (est-ce que telle 
session a atteint son nombre maximal ? est-elle encore vivante ?). On 
peut pousser plus loin si une réindexation a eu lieu...

Tout ceci serait, bien sûr, à affiner par exemple en déclarant un 
composant poolable dans Cocoon, mais là... ça sera pour plus tard :-)

A+

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