Re: [spip-dev] SPIP Party !!!

2020-05-07 Par sujet jeanmarie

Salut nicod_,

merci pour l'initiative.

C'est vrai qu'il y a une super dynamique depuis qqs temps déjà (ne 
jamais donner de dates, jamais :) ) et c'est un moment idéal pour 
renforcer tout ça et organiser une SPIP Party !


Mais... vues les conditions, ça me parait compliqué de se projeter dans 
les prochains mois vu que, au delà des risques sanitaires, on n'a aucune 
visibilité sur ce qu'on pourra faire ou non dans les mois à venir.


Tu avais une date en tête ? C'est bien qu'on garde cette dynamique, 
peut-être pour l'automne ? En se disant qu'on y verra sans doute plus 
clair dans 1 mois ou 2...


Certain.es avaient émis l'idée d'une ile en pointe Bretagne qui commence 
par Oue... et qui finit par ...ssant. Selon la période de l'année, ça 
peut être super.


Bref, ce mail pour dire que je plussoie (coef 1000) l'idée et qu'il nous 
faut juste trouver le bon timing ! Le reste suivra...


                            jeanmarie


Le 30/04/2020 à 16:03, erational a écrit :

Coucou

Cela serait chouette en effet de se retrouver.
Ca bouge beaucoup coté SPIP et une rencontre IRL serait top !

Des bises

Le 30/04/2020 à 00:01, nicod_ a écrit :

Yop,

il y a eu du mouvement ces derniers temps autour de SPIP, plein 
d'énergies combinées qui ont amené à de belles avancées.

Et on a fait du chemin, mais la route est toujours ouverte :)

C'est le moment pour organiser une grosse rencontre non ?

Allez, il suffit de lancer le mouvement, trouver un lieu, proposer 
une date...


Des pistes par là https://www.grandsgites.com ou ailleurs.

Qui c'est qui s'y colle cette année ?

La bise,
à bientôt IRL / AFK,




___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP Party !!!

2020-04-30 Par sujet erational

Coucou

Cela serait chouette en effet de se retrouver.
Ca bouge beaucoup coté SPIP et une rencontre IRL serait top !

Des bises

Le 30/04/2020 à 00:01, nicod_ a écrit :

Yop,

il y a eu du mouvement ces derniers temps autour de SPIP, plein 
d'énergies combinées qui ont amené à de belles avancées.

Et on a fait du chemin, mais la route est toujours ouverte :)

C'est le moment pour organiser une grosse rencontre non ?

Allez, il suffit de lancer le mouvement, trouver un lieu, proposer une 
date...


Des pistes par là https://www.grandsgites.com ou ailleurs.

Qui c'est qui s'y colle cette année ?

La bise,
à bientôt IRL / AFK,



--
_
https://www.erational.org

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP Party !!!

2020-04-30 Par sujet teamspipfact...@gmail.com

je suis d'accord, même si je ne participe pas
c'est vraiment pas le moment 

JE VOUS DEMANDE D'ATTENDRE minima jusqu’à Novembre avant de prendre une 
décision.


Vous serez sans doute surpris des annonces d'ici la

ps/ J'ai rien écrit, j'ai rien dit :-X



Le 30/04/2020 à 10:48, chanka...@choc0.net a écrit :

salut salut,
ça me plairait vraiment et j'ai déjà commencé à prendre des 
informations dans ma région, ou même en bourgogne où ça peut être très 
chouette et moins loin pour plus de monde, sans trouver encore le truc 
parfait... mais c'était avant cette histoire de covid, et je suis pas 
très chaud pour finaliser en ce moment. Mon entourage ne m'incite pas 
à prendre cette décision non plus, pour l'instant...



Le 30/04/2020 à 00:01, nicod_ a écrit :

Yop,

il y a eu du mouvement ces derniers temps autour de SPIP, plein 
d'énergies combinées qui ont amené à de belles avancées.

Et on a fait du chemin, mais la route est toujours ouverte :)

C'est le moment pour organiser une grosse rencontre non ?

Allez, il suffit de lancer le mouvement, trouver un lieu, proposer 
une date...


Des pistes par là https://www.grandsgites.com ou ailleurs.

Qui c'est qui s'y colle cette année ?

La bise,
à bientôt IRL / AFK,



--


chan

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


--
spipfactory.fr

Perdu dans la Galaxie SPIP ? : https://boussole.spip.net/
---
Tout SPIPeur, qui fait quelquechose,
a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément 
le contraire,
et surtout la grande armée des gens, beaucoup plus sévéres, qui ne fait rien.
Merci a ceux qui font.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP Party !!!

2020-04-30 Par sujet chanka...@choc0.net

salut salut,
ça me plairait vraiment et j'ai déjà commencé à prendre des informations 
dans ma région, ou même en bourgogne où ça peut être très chouette et 
moins loin pour plus de monde, sans trouver encore le truc parfait... 
mais c'était avant cette histoire de covid, et je suis pas très chaud 
pour finaliser en ce moment. Mon entourage ne m'incite pas à prendre 
cette décision non plus, pour l'instant...



Le 30/04/2020 à 00:01, nicod_ a écrit :

Yop,

il y a eu du mouvement ces derniers temps autour de SPIP, plein 
d'énergies combinées qui ont amené à de belles avancées.

Et on a fait du chemin, mais la route est toujours ouverte :)

C'est le moment pour organiser une grosse rencontre non ?

Allez, il suffit de lancer le mouvement, trouver un lieu, proposer une 
date...


Des pistes par là https://www.grandsgites.com ou ailleurs.

Qui c'est qui s'y colle cette année ?

La bise,
à bientôt IRL / AFK,



--


chan

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] SPIP Party !!!

2020-04-29 Par sujet nicod_

Yop,

il y a eu du mouvement ces derniers temps autour de SPIP, plein 
d'énergies combinées qui ont amené à de belles avancées.

Et on a fait du chemin, mais la route est toujours ouverte :)

C'est le moment pour organiser une grosse rencontre non ?

Allez, il suffit de lancer le mouvement, trouver un lieu, proposer une 
date...


Des pistes par là https://www.grandsgites.com ou ailleurs.

Qui c'est qui s'y colle cette année ?

La bise,
à bientôt IRL / AFK,

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP-Party dans la drôme ?

2018-01-22 Par sujet Ben.
Bonjour,
merci à toutes et à tous d'avoir donnée votre avis .

Ce que l'on a retenu c'est qu'on est grosso modo ex-aeco pour les dates (
13/20/23 ou 26/31/33 avec les peut être)   mais septembre semble la
meilleure option.

Entre temps, le week-end du 22/23 septembre qui était proposé dans le
sondage a été réservé.

Au final la SPIP-party QuiNAPasEncoreDeNomDeCode aura lieu les 28/29/30
septembre 2018 dans la Drôme.
Plus précisément ici pour les curieux / curieuses :
http://www.gite-drome-ayasses.fr/
P.S : ne réservez pas directement auprès du gite ;)
On vous refait signe très vite (enfin dès que possible) sur SPIP-Party pour
l'organisation / réservation.

SPIPement vôte
La #DrômeTeam



2018-01-11 13:42 GMT+01:00 Ben. :

> Hello,
>
> En 2015 et en 2017 certains d'entre vous on passé un bon
> moment pour une SPIP-Party à toulouse (encore MERCI la
> #TeamCassoulet ) !
>
> Et si on remettait cela en 2018 ?
>
> Histoire de changer un peu, on vous propose de
> partir dans la Drôme, entre l'Ardèche et le Vercors.
> (grosso modo autour de Valence si tu veux situer une grosse
> ville pas trop loin ;) ).
>
> Mais on a besoin de toi pour prendre la température
> et "décider" de la date, du lieu (et de sa capacité).
> Et ne pas prendre trop de risque en payant la
> caution de la location d'un gîte éventuellement
> trop grand.
>
> À Toulouse, la capacité d'hébergement était de 26 couchages,
> là nous avons des vues sur des hébergements de 40/50 couchages.
>
> On a donc le choix entre 3 propositions / dates :
> https://framadate.org/JRnEd9IfdQxwbsjb
> - les 20/21/22 avril
> - les 08/09/10 juin
> - les 21/22/23 septembre
>
> Pour le tarif, on prévoit le même budget que pour les rencontres de
> Toulouse, à affiner en fonction du nombre de personnes.
> https://party.spip.net/SPIPoulet-2-017 (Hébergement & participation).
> Environ 150 euros pour les 3 jours pour celles et ceux qui n'ont pas
> le courage de cliquer.
>
> Donc voilà, on aimerait savoir si tu viens ou pas ? (cela n'engage
> à rien hein, c'est juste pour prendre la température).
>
> Alors vas y n'hésites pas à remplir le sondage avant lundi 15 janvier:
> https://framadate.org/JRnEd9IfdQxwbsjb
>
> On doit se décider rapidement pour pouvoir réserver,
> merci de répondre avant lundi i
>
> Pleins de bisous
> Nicod et Ben.
>
>
> P.S de transparence : comme l'an dernier il y aura
> peut être une before, mais rien n'est encore sûr.
> Cela dépend des disponibilités des gîtes et on
> veut garder cette before légère à organiser et
> donc limiter le nombre de présent·e·s .
>
>
> Donc si tu lis ce mail, tu cliques et tu coches ;)
> https://framadate.org/JRnEd9IfdQxwbsjb
>
>
>
>
___
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

[spip-dev] SPIP-Party dans la drôme ?

2018-01-11 Par sujet Ben.
Hello,

En 2015 et en 2017 certains d'entre vous on passé un bon
moment pour une SPIP-Party à toulouse (encore MERCI la
#TeamCassoulet ) !

Et si on remettait cela en 2018 ?

Histoire de changer un peu, on vous propose de
partir dans la Drôme, entre l'Ardèche et le Vercors.
(grosso modo autour de Valence si tu veux situer une grosse
ville pas trop loin ;) ).

Mais on a besoin de toi pour prendre la température
et "décider" de la date, du lieu (et de sa capacité).
Et ne pas prendre trop de risque en payant la
caution de la location d'un gîte éventuellement
trop grand.

À Toulouse, la capacité d'hébergement était de 26 couchages,
là nous avons des vues sur des hébergements de 40/50 couchages.

On a donc le choix entre 3 propositions / dates :
https://framadate.org/JRnEd9IfdQxwbsjb
- les 20/21/22 avril
- les 08/09/10 juin
- les 21/22/23 septembre

Pour le tarif, on prévoit le même budget que pour les rencontres de
Toulouse, à affiner en fonction du nombre de personnes.
https://party.spip.net/SPIPoulet-2-017 (Hébergement & participation).
Environ 150 euros pour les 3 jours pour celles et ceux qui n'ont pas
le courage de cliquer.

Donc voilà, on aimerait savoir si tu viens ou pas ? (cela n'engage
à rien hein, c'est juste pour prendre la température).

Alors vas y n'hésites pas à remplir le sondage avant lundi 15 janvier:
https://framadate.org/JRnEd9IfdQxwbsjb

On doit se décider rapidement pour pouvoir réserver,
merci de répondre avant lundi i

Pleins de bisous
Nicod et Ben.


P.S de transparence : comme l'an dernier il y aura
peut être une before, mais rien n'est encore sûr.
Cela dépend des disponibilités des gîtes et on
veut garder cette before légère à organiser et
donc limiter le nombre de présent·e·s .


Donc si tu lis ce mail, tu cliques et tu coches ;)
https://framadate.org/JRnEd9IfdQxwbsjb
___
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Fil
> Petite question au passage, si on utilise le recalcul sur une page, ça
> annule le cache de tous les utilisateurs pour cette page recalculée?

Bonne idée : [10827]

-- Fil


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Sebbou
Petite question au passage, si on utilise le recalcul sur une page, ça
annule le cache de tous les utilisateurs pour cette page recalculée?

- Seb -

Le 20/11/07, Fil  a écrit :
>
> > je crois savoir comment faire, laissez moi le temps de finir :p
>
> [10824]
>
> A noter, j'en ai profité pour *éliminer* des file_exists(), même si en
> apparence il y en a un de plus sur le cache sessionné.
>
> -- Fil
> ___
> liste: http://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
>



-- 
Par respect pour l'environnement, n'imprimez ce courriel que si c'est
nécessaire.
Ensemble, sauvons notre planète!


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Stephane

Fil a écrit :

je crois savoir comment faire, laissez moi le temps de finir :p



[10824]

A noter, j'en ai profité pour *éliminer* des file_exists(), même si en
apparence il y en a un de plus sur le cache sessionné.
  


bon ben voila, je peux jeter mon bloc_perso alors...
en plus, si je comprend bien, on peut générer du cache perso pour le 
premier niveau d'appel des squelettes, c'est donc mieux que ce que je 
faisait.


c'est cool, merci.!




Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Fil
> je crois savoir comment faire, laissez moi le temps de finir :p

[10824]

A noter, j'en ai profité pour *éliminer* des file_exists(), même si en
apparence il y en a un de plus sur le cache sessionné.

-- Fil


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Fil
> >> - c'est plus performant que #CACHE{0} qui renvoie -1 et declenche un
> >> recalcul (ie une compilation du skel)
> preferable d'avoir une directive spécifique à la recompilation et que
> #CACHE{0} ne provoque qu'un calcul a chaque hit, pas un recalcul

euh tu m'étonnes, là ; si c'est le cas en effet c'est un bug.

> Ou alors il faut faire un truc a deux étages :

je crois savoir comment faire, laissez moi le temps de finir :p

-- Fil


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet cedric.mo...@yterium.com

Stephane a écrit :

cedric.mo...@yterium.com a écrit :
  

Et l'on y apprend que :
- il n'y a pas d'invalidation (au sens des vieux spip, declenchant des 
effacement en base et en fs) mais on ignore simplement le cache
  



ah ?
et il est nettoyé un jour ce fichier ?
  
- on renvoie 1, comme si la page etait périméé, qui va declencher un 
calcul de la page
  



ca c'est tres bien

  
- c'est plus performant que #CACHE{0} qui renvoie -1 et declenche un 
recalcul (ie une compilation du skel)
  



mettre le cache à 0 provoque la recompilation du squelette ?
quelle drole d'idée... pourquoi ?
  
oui l'idée m'a effleuré que ca n'etait peut être pas opti... Il serait 
preferable d'avoir une directive spécifique à la recompilation et que 
#CACHE{0} ne provoque qu'un calcul a chaque hit, pas un recalcul
Que le mecanisme est optimal dans la mesure ou si tous les internautes 
sont servis avec la meme url, il n'y a pas de moyen de differencier a 
priori le cache sans un acces en base.
  



ben si, la session...
  
oui mais pour toutes les pages dans ce cas : tu dis que tous les caches 
dependent de la session, et tu demultiplie les cache. L'inconvenient est 
que le webmestre loggué ne voit pas la meme page que le visiteur, que 
son recalcul ne sert donc à rien etc ..., et que ca fait enfler le cache.


Ou alors il faut faire un truc a deux étages :

url -> nom du cache, on lit le fichier
la on voit session dans l'id du cache
-> on recalcule le nom du cache en tenant compte de la session et on 
pioche dedans


voir si cela est faisable.
Cedric


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Stephane

cedric.mo...@yterium.com a écrit :


Et l'on y apprend que :
- il n'y a pas d'invalidation (au sens des vieux spip, declenchant des 
effacement en base et en fs) mais on ignore simplement le cache
  


ah ?
et il est nettoyé un jour ce fichier ?
- on renvoie 1, comme si la page etait périméé, qui va declencher un 
calcul de la page
  


ca c'est tres bien

- c'est plus performant que #CACHE{0} qui renvoie -1 et declenche un 
recalcul (ie une compilation du skel)
  


mettre le cache à 0 provoque la recompilation du squelette ?
quelle drole d'idée... pourquoi ?
Que le mecanisme est optimal dans la mesure ou si tous les internautes 
sont servis avec la meme url, il n'y a pas de moyen de differencier a 
priori le cache sans un acces en base.
  


ben si, la session...


Le webmestre qui veut optimiser son site peut, comme auparavant :
- utiliser un marqueur de cache reprenant la session si toutes les pages 
sont specifiques à chaque internaute :
-> ainsi chaque internaute a son cache, et #SESSION ne provoquera 
aucun calcul supplementaire
  
oui mais tu ne peux avoir ca que dans un inclure, le cache correspondant 
au squelette de premier niveau, lui, ne peut pas etre different d'une 
session à l'autre.
effectivement, si tu fais du "cache perso" (en mettant id_auteur dans le 
contexte), deux sessions n'utiliseront pas le meme cache effectivement, 
donc l'"invalidation" ne devrait jamais se produire.

mais ca reste à verifier...

- utiliser un session.php pour generer un cache specifique à chaque 
internaute sur les noisettes specifiques
  


si le but est de faire du cache perso, pour le coup, pas besoin de 
script specifique si tu utilise #SESSION au premier niveau.
tu peux passer directement #SESSION{id_auteur} au contexte de l'inclure 
(idem pour des #INCLURE)
Le mecanisme est donc le meilleur possible sans aucune intervention du 
developpeur du site, sans pour autant degrader les perf des sites dont 
le cache a été bien géré en fonction de la session.
  


si ce n'est le premier niveau, mais la, à part hacker spip.php, il n'y a 
pas vraiment de solution.
sauf si #SESSION provoquait un cache personnel sans s'occuper des 
changements de session



La seule vrai question est donc :
- faut il faciliter ainsi la vie des debutants en leur donnant 
l'impression que ca marche tout seul, mais au prix d'un calcul à chaque 
hit, plutot que de laisser spip ressortir un cache inadequat ?

Et les reponses possibles sont multiples :
- oui si l'on considère que n'y comprenant rien, le debutant finira par 
mettre un #CACHE{0} qui est pire en perfo
- non si l'on se dit que l'on masque trop la complexité et le coût en 
perfo que cela entraine.
  


utilisant les caches perso depuis longtemps, je comprend que ca soit 
trop demander à un webmaster que de comprendre le fonctionnement du 
cache Spip pour ecrire un squelette contenant un peu de personnalisation.

En ca, la balise SESSION est tres bien et joue bien son role.

Celui qui comprend ce qu'il fait et veut bien maitriser les chose peut, 
comme moi, ne pas l'utiliser et preferer son propre script.


Maintenant si la balise #SESSION provoquait du cache perso, ca rendrait 
le meme service et je l'utiliserai au lieu de mon script.

par contre ca risquerait de faire grossir le cache "actif" inutilement.

Donc en l'etat, c'est sans doute le meilleur compromis.

La question est plutot, amha, doit-on fournir en plus des armes plus 
pointues aux webmasters ?


Ca fait un moment que je dis qu'au final, un balise dynamique 
d'inclusion ferait le meme boulot qu'un script mettant id_auteur dans le 
contexte.
Mais au niveau de la syntaxe, c'est certes plus "propre", mais pas 
forcement plus simple à comprendre :
#INCLURE_PERSO{monsquelette} au lieu de 
, ca parait moins évident et 
il risque d'y avoir confusion avec #INCLURE qui fait justement l'inverse...
et puis au moins, si on fait 
, on se rend compte qu'on ne 
peut pas faire #INCLURE(bloc_perso.php)


mes 2 sous


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet cedric.mo...@yterium.com

Pierre FICHES a écrit :
Je prolonge ici une discussion commencée à la SPIP Party de  
Clermont.


À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un  
squelette
SPIP contient la balise #SESSION, alors un cache spécifique est  
créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages  
vues par
l'auteur 1 sont vidées du cache pour être recalculées pour  
l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de  
recalcul que ça
peut-être si le squelette en question est inclus dans chaque  
page du site.




  

objection, ouie dire votre honneur




Peut etre (j'ai pas vérifié), mais c'est Fil qui les colportait...
:)

D'après lui le cache etait invalidé lorsqu'une nouvelle session  
faisait

appel à ce meme cache.
c'est pas ca ?

  

Je ne sais pas.
Je n'ai jamais vu le code correspondant à ça, et je découvre.
Et pour le moins les descriptions litéralles faites ici pour quelqu'un
qui n'a pas assisté à la concervsation (moi en l'occurence) sont assez
... imaginatives, non ?

Alors lancer un fil sur une discussion rapportée et interpretée me
parait peu productif,
le minimum serait de referencer le code concerné ou de bencher avec un
cas test démonstratif.
Parce que, pour ce que j'en sais, fil est assez sensible aux aspects
perfos pour ne pas faire n'importe quoi ...

En ce qui me concerne je ne me prononcerai sur le fond qu'après  
avoir vu

des éléments tangibles ...




Au cas où ça puisse aider l'annonce de Fil en Août :

De : Fil 
Date : 25 août 2007 01:27:38 HAEC
À : spip-c...@rezo.net
Objet : [spip-dev] !  la balise #SESSION

La balise #SESSION est arrivée ; lorsqu'elle est calculée, elle
indique le contenu de la session courante, sous forme d'un tableau
(comme #ENV) :

[Hello (#SESSION{nom}|typo)]

Elle indique aussi au cache qu'il doit s'invalider si la session change.

Si le visiteur n'est pas connectée, #SESSION donne une chaîne vide --
ce qui permet de faire des tests : [(#SESSION|?{Salut !})].

Bon à savoir : n'importe quelle balise peut déclencher  l'invalideur
de session en invoquant
 $p->desc['session'] = true;

A signaler, *aucun* traitement (à part interdire_script) n'est
appliqué à cette balise, donc pour avoir le nom du visiteur, il *faut*
faire quelque chose comme [(#SESSION{nom}|typo)].

Le tableau contient :

id_auteur
nom
login
email
statut
lang
ip_change
hash_env

les deux derniers n'ont pas d'interet, ils sauteront probablement ; il
manque la bio, a voir si on l'ajoute (une boucle AUTEURS suffit de
toutes façons à la récupérer si besoin).
  

Merci Pierre
Et pour completer cela, le code concerné est
Ligne 100 de public/cacher

   // Si la page a un invalideur de session 'zz', on ignore le cache
   // si le visiteur n'a pas la meme session 'zz'
   if (isset($page['invalideurs'])
   AND isset($page['invalideurs']['session'])
   AND $page['invalideurs']['session'] !== spip_session()) {
   #spip_log('Session: \''.$page['invalideurs']['session'] . '\' != 
\''.spip_session().'\'');

   return 1;
   }

   // Sinon comparer l'age du fichier a sa duree de cache
   $duree = intval($page['entetes']['X-Spip-Cache']);
   if ($duree == 0)  #CACHE{0}
   return -1;
   else if ($date + $duree < time())
   return 1;
   else
   return 0;

Et l'on y apprend que :
- il n'y a pas d'invalidation (au sens des vieux spip, declenchant des 
effacement en base et en fs) mais on ignore simplement le cache
- on renvoie 1, comme si la page etait périméé, qui va declencher un 
calcul de la page
- c'est plus performant que #CACHE{0} qui renvoie -1 et declenche un 
recalcul (ie une compilation du skel)


Que le mecanisme est optimal dans la mesure ou si tous les internautes 
sont servis avec la meme url, il n'y a pas de moyen de differencier a 
priori le cache sans un acces en base.

Le webmestre qui veut optimiser son site peut, comme auparavant :
- utiliser un marqueur de cache reprenant la session si toutes les pages 
sont specifiques à chaque internaute :
   -> ainsi chaque internaute a son cache, et #SESSION ne provoquera 
aucun calcul supplementaire
- utiliser un session.php pour generer un cache specifique à chaque 
internaute sur les noisettes specifiques


Le mecanisme est donc le meilleur possible sans aucune intervention du 
developpeur du site, sans pour autant degrader les perf des sites dont 
le cache a été bien géré en fonction de la session.

La seule vrai question est donc :
- faut il faciliter ainsi la vie des debutants en leur donnant 
l'impression que ca marche tout seul, mais au prix d'un calcul à chaque 
hit, plutot que de laisser spip ressortir un cache inadequat ?

Et les reponses possibles sont multiples :
- oui si l'on considère que n'y comprenant rien, le debutant finira par 
mettre un #CACHE{0} qui est pire en perfo
- non si l'on se dit que l'on masque trop la complexité et le coût en 
perfo que cela entraine.



Cédric
(qui trouve que vérifier ses sources, 

Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet RealET

* Stephane tapuscrivait, le 20/11/2007 10:50:

cedric.mo...@yterium.com a écrit :

RealET a écrit :
  

Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.
  


objection, ouie dire votre honneur
  


Peut etre (j'ai pas vérifié), mais c'est Fil qui les colportait...
:)

D'après lui le cache etait invalidé lorsqu'une nouvelle session faisait 
appel à ce meme cache.

Bon, au moins, nous sommes 2 à avoir compris la même chose.


c'est pas ca ?



--
RealET



Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Pierre FICHES


Le 20 nov. 07 à 11:00, cedric.mo...@yterium.com a écrit :


Stephane a écrit :

cedric.mo...@yterium.com a écrit :


RealET a écrit :


Je prolonge ici une discussion commencée à la SPIP Party de  
Clermont.


À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un  
squelette
SPIP contient la balise #SESSION, alors un cache spécifique est  
créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages  
vues par
l'auteur 1 sont vidées du cache pour être recalculées pour  
l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de  
recalcul que ça
peut-être si le squelette en question est inclus dans chaque  
page du site.





objection, ouie dire votre honneur




Peut etre (j'ai pas vérifié), mais c'est Fil qui les colportait...
:)

D'après lui le cache etait invalidé lorsqu'une nouvelle session  
faisait

appel à ce meme cache.
c'est pas ca ?


Je ne sais pas.
Je n'ai jamais vu le code correspondant à ça, et je découvre.
Et pour le moins les descriptions litéralles faites ici pour quelqu'un
qui n'a pas assisté à la concervsation (moi en l'occurence) sont assez
... imaginatives, non ?

Alors lancer un fil sur une discussion rapportée et interpretée me
parait peu productif,
le minimum serait de referencer le code concerné ou de bencher avec un
cas test démonstratif.
Parce que, pour ce que j'en sais, fil est assez sensible aux aspects
perfos pour ne pas faire n'importe quoi ...

En ce qui me concerne je ne me prononcerai sur le fond qu'après  
avoir vu

des éléments tangibles ...



Au cas où ça puisse aider l'annonce de Fil en Août :

De : Fil 
Date : 25 août 2007 01:27:38 HAEC
À : spip-c...@rezo.net
Objet : [spip-dev] !  la balise #SESSION

La balise #SESSION est arrivée ; lorsqu'elle est calculée, elle
indique le contenu de la session courante, sous forme d'un tableau
(comme #ENV) :

   [Hello (#SESSION{nom}|typo)]

Elle indique aussi au cache qu'il doit s'invalider si la session change.

Si le visiteur n'est pas connectée, #SESSION donne une chaîne vide --
ce qui permet de faire des tests : [(#SESSION|?{Salut !})].

Bon à savoir : n'importe quelle balise peut déclencher  l'invalideur
de session en invoquant
$p->desc['session'] = true;

A signaler, *aucun* traitement (à part interdire_script) n'est
appliqué à cette balise, donc pour avoir le nom du visiteur, il *faut*
faire quelque chose comme [(#SESSION{nom}|typo)].

Le tableau contient :

id_auteur
nom
login
email
statut
lang
ip_change
hash_env

les deux derniers n'ont pas d'interet, ils sauteront probablement ; il
manque la bio, a voir si on l'ajoute (une boucle AUTEURS suffit de
toutes façons à la récupérer si besoin).

-- Fil

irc://irc.freenode.net/spip








Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet cedric.mo...@yterium.com

Stephane a écrit :

cedric.mo...@yterium.com a écrit :
  

RealET a écrit :
  


Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.
  

  

objection, ouie dire votre honneur
  



Peut etre (j'ai pas vérifié), mais c'est Fil qui les colportait...
:)

D'après lui le cache etait invalidé lorsqu'une nouvelle session faisait 
appel à ce meme cache.

c'est pas ca ?
  

Je ne sais pas.
Je n'ai jamais vu le code correspondant à ça, et je découvre.
Et pour le moins les descriptions litéralles faites ici pour quelqu'un 
qui n'a pas assisté à la concervsation (moi en l'occurence) sont assez 
... imaginatives, non ?


Alors lancer un fil sur une discussion rapportée et interpretée me 
parait peu productif,
le minimum serait de referencer le code concerné ou de bencher avec un 
cas test démonstratif.
Parce que, pour ce que j'en sais, fil est assez sensible aux aspects 
perfos pour ne pas faire n'importe quoi ...


En ce qui me concerne je ne me prononcerai sur le fond qu'après avoir vu 
des éléments tangibles ...

Cédric

mes deux sous de non contribution :p


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Stephane

cedric.mo...@yterium.com a écrit :

RealET a écrit :
  

Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.
  


objection, ouie dire votre honneur
  


Peut etre (j'ai pas vérifié), mais c'est Fil qui les colportait...
:)

D'après lui le cache etait invalidé lorsqu'une nouvelle session faisait 
appel à ce meme cache.

c'est pas ca ?


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet RealET

* cedric.mo...@yterium.com tapuscrivait, le 20/11/2007 10:24:

RealET a écrit :

Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.
  

objection, ouie dire votre honneur
on peut se baser sur des faits réels ou du code ?
tu fais allusion a quoi ?

La discussion était entre Fil et moi.
Les affirmations sur le fonctionnement du cache sont ce que j'ai compris 
de ce que Fil disait.


--
RealET



Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet cedric.mo...@yterium.com

RealET a écrit :

Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.
  

objection, ouie dire votre honneur
on peut se baser sur des faits réels ou du code ?
tu fais allusion a quoi ?
Cédric



Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Stephane

Grégoire a écrit :

Stephane a écrit :
  

RealET a écrit :


[...]
  
m'enfin, tu peux bien mettre ce que tu veux dans le contexte ou meme 
generer le nom du squelette, il suffit d'appeler ton propre script :



@++



Bonsoir

Mais combien ne le feront pas (pour contourner ce bug???)
  


quel bug ?
on parle de choix d'implementation la, pas de bug.
la balise SESSION, c'est pour ceux qui ne veulent pas se poser de 
question de cache justement, alors qu'ils ne se la posent pas.
si tu te poses la question du cache, tu geres ton contexte (c'est ce que 
je fais depuis les toutes premieres 1.8, c'etait à mes yeux le plus gros 
apport du compilo d'ESJ : la maitrise du contexte)

Après, Spip passera pour un CMS lourd...

Donc, je pense que c'est à discuter. Bug ou pas, option par défaut
ou pas?

Et si l'on voulait que dans le cas de l'utilisation de la balise
#SESSION le cache soit à zéro? comment on ferait?
  


ca, ca n'a vraiment aucun sens, donc on ne fait pas.
si tu veux un cache à 0, tu mets le cache à 0
La question etait plutot cache perso, ou invalidation au changement de 
session.
La solution retenue a le gros avantage de ne pas faire gonfler le cache 
tout en limitant les risques de surcharge (le gars qui appuie 350 fois 
sur F5 parce qu'il est énérvé...)


A la limite, il manque peut etre un  au lieu de la sale 
syntaxe passant le nom du script qui au final, dans 95% des cas, ne fait 
qu'ajouter l'id_auteur au contexte.


@++


Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Grégoire
Stephane a écrit :
> RealET a écrit :
>> [...]
> 
> m'enfin, tu peux bien mettre ce que tu veux dans le contexte ou meme 
> generer le nom du squelette, il suffit d'appeler ton propre script :
> 
> 
> @++

Bonsoir

Mais combien ne le feront pas (pour contourner ce bug???)

Après, Spip passera pour un CMS lourd...

Donc, je pense que c'est à discuter. Bug ou pas, option par défaut
ou pas?

Et si l'on voulait que dans le cas de l'utilisation de la balise
#SESSION le cache soit à zéro? comment on ferait?

A bientôt
Grégoire



Re: [spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet Stephane

RealET a écrit :

Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.


D'où l'idée de rajouter dans le nom du fichier de cache l'id de l'auteur 
concerné par ce cache.


Comme ça, à chaque hit, et selon l'auteur connecté, on va chercher le 
cache idoine ou on le crée au besoin.


Et plus de recalcul en ping pong.

  

un genre de bloc_perso quoi ?
désolé James, j'ai pas pu m'empecher !
:)

ceci dit je trouve ca plutot interessant.
je croyais que session mettait le cache à 0 et c'est bien plus efficace 
comme ca.


m'enfin, tu peux bien mettre ce que tu veux dans le contexte ou meme 
generer le nom du squelette, il suffit d'appeler ton propre script :



@++


[spip-dev] [SPIP Party Clermon, suites] Cache et balise #SESSION de SPIP

2007-11-20 Par sujet RealET

Je prolonge ici une discussion commencée à la SPIP Party de Clermont.

À ma grande surprise, j'y ai appris qu'en l'état, lorsqu'un squelette 
SPIP contient la balise #SESSION, alors un cache spécifique est créé.

Jusque là, ça va.
Mais que si un 2e auteur navigue sur le site, alors, les pages vues par 
l'auteur 1 sont vidées du cache pour être recalculées pour l'auteur 2.
Vous imaginez le ping pong d'invalidation de cache et de recalcul que ça 
peut-être si le squelette en question est inclus dans chaque page du site.


D'où l'idée de rajouter dans le nom du fichier de cache l'id de l'auteur 
concerné par ce cache.


Comme ça, à chaque hit, et selon l'auteur connecté, on va chercher le 
cache idoine ou on le crée au besoin.


Et plus de recalcul en ping pong.

--
RealET