>> B) conservation des caches pour differentes sessions, la, on recompile le cache a chaque session.
une idée comme ça, ajouter spip_session() pour le calcul du nom du cache :
Oui c'est certain ; en revanche tu n'as plus le même cache que tes
visiteurs pour *aucun* fichier cache, donc le bouton "recalculer cette
page" n'a plus de sens. Pas forcément grave d'ailleurs...
B) conservation des caches pour differentes sessions, la, on recompile le cache a chaque session.
une idée comme ça, ajouter spip_session() pour le calcul du nom du cache :
Oui c'est certain ; en revanche tu n'as plus le même cache que tes
visiteurs pour *aucun* fichier cache, donc le bouton "recalculer cette
page" n'a plus de sens. Pas forcément grave d'ailleurs...
moi je persiste à ne pas comprendre la prise de tete autour de la balise session... (je t'epargne le couplet sur le cache perso/par staut... )
tu n'as jamais une page completement specifique à un utilisateur.
Il suffit de sortir dans des inclusions ce qui est specfique à l'utilisateur, son statut ou la couleur de ses chaussettes et d'appeler une inclusion qui sit elle capable de mettre la specificité dans le contexte.
A partir de la tu n'as jamais de collision de cache.
tu n'as jamais une page completement specifique à un utilisateur.
Il suffit de sortir dans des inclusions ce qui est specfique à
l'utilisateur, son statut ou la couleur de ses chaussettes et d'appeler
une inclusion qui sit elle capable de mettre la specificité dans le
contexte.
Oui c'est la balise session actuelle, avec
<INCLURE(session.php){environnement qui va bien}>
L'idée de James ici c'est de pouvoir déterminer automagiquement que la
page change en fonction de la session, dès qu'elle contient #SESSION ;
donc se débarrasser de session.php ; ma remarque porte sur son commit
qui élimine le cache commun aux utilisateurs enregistrés et non
enregistrés.
Mais à mon avis tu as raison, la complexité de ce qu'il faut faire
pour éliminer session.php est trop importante pour que ça vaille la
peine.