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

[Frédéric Glorieux]

> > Ce que je peux dire, c'est que l'architecture de SDX ne pose pas de
> > problème particulier pour implanter un mécanisme de cache des
requêtes,
> > du moins il ne m'en vient pas à l'esprit. Par contre, si on voulait
> > implanter ce type de fonctionnalités, il faudrait répondre à cette
> > question fondamentale : comme savoir que deux requêtes de recherche
sont
> > identiques?

Il me semble qu'il suffirait d'assurer l'univocité des chaînes de
requête Lucene (ce qui limite le support du cache à un moteur de
recherche dont la requête est représentable à une chaîne), d'autre part,
il faudrait associer les "locations", sur lesquelles cette chaîne a été
exécutée.

> Pour moi deux requêtes sont identiques si l'url qui les déclenche est
> identique? mais je suppose que si vous posez la question c'est que ce
> n'est pas si simple... ;-)

Dans la mesure ou des paramètres de requête peuvent être statique ou en
session, je ne sais pas si une URL suffit à représenter une requête.
D'autant que cocoon permet de nombreux mécanismes d'URL virtuelles.

> Pourtant, il semble que:
> - à corpus identique
> - à xsp inchangées
> deux url identiques produisent exactement la même requête, et donc
> le même objet résultat?

Sauf si une xsp va chercher des informations ailleurs.

> Il peut arriver que des urls différentes produisent le même objet
> résultat 

Et dans le cas d'une page qui a besoin de deux requêtes ? Comment
déduire d'une URL qu'il y a deux objets Results ?

> Partir des urls est peut-être brutal, et surtout c'est peut-être
> le signe que le cache pourrait être pris en charge par le serveur
> web au lieu de SDX; à l'intérieur de SDX il serait peut-être plus
> fin de comparer les éléments sdx:query ...?

        Cocoon propose de nombreux mécanismes de cache. J'ai déjà testé
le résultat avec des transformations statiques  (pipeline du genre
XML/XSL/HTML), avec ou sans paramètres. Evidemment le cache de page
dynamique est bien différent, j'ai lu
http://wiki.cocoondev.org/Wiki.jsp?page=XSPCachingWithCocoonHEAD
mais je n'ai jamais essayé d'implanter. 
        L'exemple "cacheable.xsp" dans les sources cocoon est plus
parlant, il montre comment l'identifiant de cache est générable selon
les paramètres au choix du développeur. Peut-être que cela peut vous
suffire? Par contre pour "décacher", on peut brutalement redémarrer le
serveur, ou rentrer plus en détail dans la classe. 
        Ne pas oublier, ceci ne cache pas à proprement parler des
résultats, mais l'XML généré (avec en particulier chaque page de
navigation dans les résultats, il faut donc préciser les paramètres de
page, d'un qid fixé, et ne pas autoriser des nombres de résultats par
page trop dynamique...). Ce n'est pas très optimisé, mais si c'est
cocoon qui s'en charge...