TR : [sdx-users] Mécanisme de cache?

[Frédéric Glorieux]

> Aujourd'hui dans SDX, si j'ai bien compris, les requêtes
> sont cachées pour une session donnée: on conserve en mémoire

c'est le mécanisme de session de tomcat

> (ou sur le disque?) le résultat des dix dernières requêtes

5 dernières (cela semblait raisonnable pour une seule fenêtre de
navigateur)

> de la session, et on peut y revenir ou travailler dessus
> (réduire / augmenter les résultats).

Plus exactement, il a d'abord était conçu pour naviguer d'une page à
l'autre sans ré-executer la requête.

> Par contre une requête n'est pas cachée entre plusieurs
> sessions / plusieurs utilisateurs: si deux utilisateurs
> différents font la même requête à quelques secondes
> d'intervalle, la recherche est menée deux fois: correct?

Oui. Nous n'avons pas encore trouvé de mécanisme générique vraiment
optimal pour une cache de requête partagée par toute une application.
(voir mail de Martin)

> D'une manière générale d'ailleurs, il serait intéressant de
> cacher les résultats d'une recherche tant que le corpus n'a
> pas évolué (entre deux indexations), puisqu'il est impossible
> qu'à corpus identique les résultats soient différents?

C'est souhaitable en effet, à court terme une application peut elle-même
cacher les objets qu'elle sait être pérenne et partageable pour tous les
utilisateurs (ici c'est au développeur de savoir, sdx ne préjuge de
rien)

On pourrait essayer l'objet
org.apache.avalon.framework.context.DefaultContext

Voici quelques idées en vrac.

En attendant de modifier la taglib sdx.xsl, 
Il faudrait tester ainsi (<xsp:logicsheet
location="???/mataglib_modifiee.xsl"/>)

ajouter une variable de classe Context context,
modifier la méthode contextualise()

  Context context;
  /** Contextualize this class, instantiate by cocoon */
  public void contextualize(Context context) throws ContextException
  {
    this.context=context;
  }

De là on a accès à 

    context.put(key, value);
    context.get(key);

Un développeur saura y cacher avec précaution ses results par l'xsp
d'indexation, et les reprendre dans sa page d'accueil. 

Un objet context ne doit probablement pas survivre à un redémarrage de
tomcat (prévoir à recacher vos requêtes). On ne connaît pas vraiment les
comportements de synchronisation (que se passe-t-il si 2 personnes
cachent en même temps une requête).

Une autre piste