[spip-dev] calculs en background

Dev
1

J'ai procédé à qq expérimentations à propos du calcul en background.
Il y a en fait 2 problèmes.

1. Spip ne profite pas pleinement du protocole http/1.1 en ce qu'il ne calcule pas, et donc
ne transmet pas, le Header "content-length"; du coup, le client est obligé d'attendre la fin
de l'exécution du processus serveur avant de conclure qu'il a tout reçu.

2. Certains clients ignorent ce header, et attendent donc la fin du processus serveur quand bien meme celui-ci leur a indiqué la taille de ce qu'il transmet et qu'il a fini de le transmettre.

On peut tester son client en mettant le fichier suivant dans le répertoire principal de Spip:

<?php
  Header("Content-Type: text/html;");
  $a= '<html><body>foo<img src="ecrire/img_pack/warning.gif"></body></html>';
  Header("Content-Length: " . strlen($a) .";");
  echo $a;
  flush();
  sleep(3);
?>

Résultats des courses sauf erreur de ma part:
  IE lance le GET IMG avant le sleep sour MacOSX
  Safari (MacOSX) lance le GET IMG après le sleep
  Mozilla lance le GET IMG après le sleep sous MacOSX
  Netscape lance le GET IMG avant le sleep sous Linux

Il faudrait tester IE sur la plate-forme dont le nom m'échappe,
mais le fait qu'il existe déjà 2 clients sur les 2 plates-formes testées
qui profitent du Content-length mmontre que Spip pourrait utilement calculer ce header.

      Emmanuel

2

Je pense que la suggestion de faire register_shutdown_function() a plus
d'avenir, même si elle n'exclut pas de faire en plus Content-Length si on
trouve comment le calculer.

1. Spip ne profite pas pleinement du protocole http/1.1 en ce qu'il ne
calcule pas, et donc ne transmet pas, le Header "content-length"; du coup,
le client est obligé d'attendre la fin de l'exécution du processus serveur
avant de conclure qu'il a tout reçu.

-- Fil

3

De ce que je comprends de ton souci et de la doc de register_shutdown_function,
je n'ai pas l'impression que celle-ci réponde à celui-là. Cette fonction sert
lorsque que le client ferme la connexion de sa propre initiative, alors que le
problème est au contraire une demande de fermeture faite par le serveur.
De ce que je connais de http, je ne vois pas ce que l'on peut faire d'autre
que de calculer le content-length, en espérant que le client est suffisamment
smart pour en ternir compte.

A+

      Emmanuel

4

Moi je ne compterais ni sur l'un ni sur l'autre :
- register_shutdown_function(), il est plus raisonnable de le désactiver
sur un hébergeur mutualisé ; et même, on ne sait pas si cette fonction
aura le comportement souhaité partout
- quant au Content-Length, c'est impossible à moins de bidouilles
particulièrement laides, puisqu'on laisse le webmestre exécuter du PHP
depuis les squelettes.

Amicalement

Antoine.

5

Pardon, mais mon avis est inverse:
ce qui est laid, et, de plus, inefficace,
c'est d'exécuter du PHP dans les squelettes.
Dans l'état actuel de Spip, il n'est pas sorcier
de regarder si le résultat d'un squelette est dépourvu de balise '<?PHP';
si tel est le cas, on peut calculer le content-length
et en prime on peut balancer ce résultat par un get_content
plutot qu'un include, autrement dit on gagne une passe d'analyse syntaxique,
ce qui n'est pas rien.

A+

      Emmanuel

6

Dans l'état actuel de Spip, il n'est pas sorcier
de regarder si le résultat d'un squelette est dépourvu de balise
'<?PHP';

Dans la plupart des cas il n'en est pas dépourvu. De plus avoir deux
branches de traitement différentes selon la présence ou non de <?php
est le meilleur moyen d'avoir des erreurs bizarres.

si tel est le cas, on peut calculer le content-length

C'est sans compter ce qui aura pu être émis avant ou après, ainsi que
d'autres détails comme les directives PHP "append" et "prepend". Enfin
bref c'est beaucoup d'ennuis pour pas grand'chose.

ciao

Antoine.

7

Dans l'état actuel de Spip, il n'est pas sorcier
de regarder si le résultat d'un squelette est dépourvu de balise
'<?PHP';

Dans la plupart des cas il n'en est pas dépourvu.

Aucun des squelettes standard n'en a.
En revanche il est vrai que le compilateur standard en ajoute,
mais j'avais commencé à les éliminer dans ma version du compilateur,
et il serait possible de les retirer tous à terme.

De plus avoir deux
branches de traitement différentes selon la présence ou non de <?php
est le meilleur moyen d'avoir des erreurs bizarres.

Bof. Remplacer "include" par, en gros, "if (strpos(p,'?php')) eval(p) else echo(p)"
me parait beaucoup moins risqué que les 2 branches différentes existant actuellement,
fondées sur la nullite d'une variable "ajout_forum" dont tout Spipeur écrivant des scripts a grandement intéret à connaître le traitement ultra particulier.

si tel est le cas, on peut calculer le content-length

C'est sans compter ce qui aura pu être émis avant ou après,

Je ne comprends pas: Spip envoie déjà des Header car il sait qu'il est
le seul à émettre; le content-length ne serait qu'un Header de plus
et si celui-ci ne marchait pas, les autres non plus.

ainsi que d'autres détails comme les directives PHP "append" et "prepend".

Là j'avoue mon ignorance, et même mon incapacité à trouver dans la doc
php de quoi il s'agit.

Enfin bref c'est beaucoup d'ennuis pour pas grand'chose.

Si on a décidé de mettre au point http/1.1 il y a pourtant des raisons.
Je ferai remarquer que l'introduction du content-length induirait aussi
automatiquement la gestion par Spip des connexions persistantes,
autrement dit la disparition des suites close/open en rafale (pour les
images en particulier) que subissent actuellement les serveurs abritant Spip.

A+

      Emmanuel

8

Bof. Remplacer "include" par, en gros, "if (strpos(p,'?php')) eval(p)
else echo(p)"

Je n'aime pas du tout eval() qui n'est pas garanti de fonctionner
exactement comme un include, et qui peut gêner d'éventuelles
optimisations extérieures (type accélérateurs de script,
php_accelerator...).

Je vois eval() comme un moyen d'exécuter une ou deux lignes de code
générées dynamiquement, mais pas un fichier entier.

D'autre part le PHP généré actuellement est réellement utile (par
exemple en cas d'URLs customisées non-triviales comme celles du Diplo).

Je ne comprends pas: Spip envoie déjà des Header car il sait qu'il est
le seul à émettre; le content-length ne serait qu'un Header de plus
et si celui-ci ne marchait pas, les autres non plus.

Le problème, c'est que le Content-Length peut être erroné au regard de
la longueur réelle des données envoyées. Il suffit pour cela qu'il y ait
un espace en trop à la fin d'un script (par exemple un
mes_fonctions.php3), ou des données supplémentaires (comme le formulaire
admin), ou des scripts spéciaux installés par le webmestre, ou n'importe
quelle pétouille qui fait qu'il n'est pas garanti que le seul contenu
envoyé est bien celui du squelette.

Encore plus compliqué à traiter : les balises <INCLURE...>.

Là j'avoue mon ignorance, et même mon incapacité à trouver dans la doc
php de quoi il s'agit.

Ce sont des directives du php.ini qui permettent d'inclure un contenu
automatique avant et après le contenu généré par PHP.

a+

Antoine.

9

Bof. Remplacer "include" par, en gros, "if (strpos(p,'?php')) eval(p)
else echo(p)"

Je n'aime pas du tout eval() qui n'est pas garanti de fonctionner
exactement comme un include, et qui peut gêner d'éventuelles
optimisations extérieures (type accélérateurs de script,
php_accelerator...).

Je vois eval() comme un moyen d'exécuter une ou deux lignes de code
générées dynamiquement, mais pas un fichier entier.

Les langages de programmation interprétés sont fondés sur
une phase de lecture suivi d'une phase d'évaluation;
utiliser Eval consiste simplement à court-circuiter la séquence
d'instructions consistant à créer un fichier puis à l'inclure.
Eval n'est pas un ajout au langage, mais le coeur de celui-ci:
le comportement est donc le même tout simplement parce que c'est
le meme programme qui est exécuté, que ce soit une chaine de deux
lignes ou un fichier d'un mega.
Autrement dit, tel M. Jourdain, tu utilises Eval sans le savoir
dès que tu inclus un fichier.

Quant aux optimisations, c'est une bonne chose, où est le problème ?

D'autre part le PHP généré actuellement est réellement utile (par
exemple en cas d'URLs customisées non-triviales comme celles du Diplo).

Que Spip ne suffise pas toujours à rédiger un squelette, c'est possible;
mais si on ne cherche pas à réduire ces cas, on donne des arguments pour
se faire entendre dire que, tant qu'à faire, autant faire du PHP à 100%.

Le problème, c'est que le Content-Length peut être erroné au regard de
la longueur réelle des données envoyées. Il suffit pour cela qu'il y ait
un espace en trop à la fin d'un script (par exemple un
mes_fonctions.php3), ou des données supplémentaires (comme le formulaire
admin), ou des scripts spéciaux installés par le webmestre, ou n'importe
quelle pétouille qui fait qu'il n'est pas garanti que le seul contenu
envoyé est bien celui du squelette.

Ca s'appelle un bug, et ça se corrige.

Encore plus compliqué à traiter : les balises <INCLURE...>.

Le compilateur que j'ai proposé est réentrant car il n'utilise aucune variable globale:
j'ai déjà fait l'essai de réaliser l'include au moment de la compilation plutot
qu'à chaque accès (gain en temps, perte en espace comme d'habitude): aucun pb.

Là j'avoue mon ignorance, et même mon incapacité à trouver dans la doc
php de quoi il s'agit.

Ce sont des directives du php.ini qui permettent d'inclure un contenu
automatique avant et après le contenu généré par PHP.

L'utilisation des header fait qu'il est impossible d'utiliser ça avant le contenu;
pour l'après, cite moi UNE installation de Spip où le php est installé comme ça.

A+

10

Eval n'est pas un ajout au langage, mais le coeur de celui-ci:
le comportement est donc le même tout simplement parce que c'est
le meme programme qui est exécuté, que ce soit une chaine de deux
lignes ou un fichier d'un mega.
Autrement dit, tel M. Jourdain, tu utilises Eval sans le savoir
dès que tu inclus un fichier.

Merci de me prendre pour un con.
eval() est une fonction spécifique du langage, qu'elle fasse appel à
l'interpréteur ne change rien à sa spécificité. Tu l'as bien vu toi-même
quand tu as fait ton compilateur, puisque tu as découvert qu'il fallait
enlever le <?php initial, etc.
Je ne fais pas assez confiance aux développeurs de PHP pour utiliser
eval() sur des bouts de code qui peuvent être assez complexes et
contenir des constructions imprévisibles. Je ne veux pas avoir à gérer
des bugs obscurs liés à une éventuelle non-réentrance de certaines
fonctions de l'interpréteur (note que PHP transforme normalement un
script en byte-code avant de l'exécuter, ce qui veut bien dire qu'eval
est un cas particulier puisque là le script n'est pas connu avant
l'exécution).

Quant aux optimisations, c'est une bonne chose, où est le problème ?

Tu peux relire ma phrase ? Je dis qu'eval() peut _gêner_ des
optimisations extérieures.

> D'autre part le PHP généré actuellement est réellement utile (par
> exemple en cas d'URLs customisées non-triviales comme celles du Diplo).

Que Spip ne suffise pas toujours à rédiger un squelette, c'est possible;

Tu n'as pas compris. Le PHP ajouté automatiquement _par SPIP_ ne peut
pas être éliminé de façon générale. C'est tout.

Ca s'appelle un bug, et ça se corrige.

?? Eh ben, propose un patch, si tu penses que "ça s'appelle un bug et
que ça se corrige". Et explique-nous comment tu vas faire pour éviter
que le webmestre envoie ses propres données à l'écran sans informer
SPIP. On en revient toujours au même problème : tu veux que SPIP se
comporte comme si le contenu envoyé à l'écran provenait uniquement des
squelettes, alors que rien ne garantit un tel comportement, à quelque
niveau que ce soit.

> Encore plus compliqué à traiter : les balises <INCLURE...>.

Le compilateur que j'ai proposé est réentrant car il n'utilise aucune
variable globale:

Et quel est le rapport avec la génération du Content-Length ?? Tu ne
réponds pas au problème.

j'ai déjà fait l'essai de réaliser l'include au moment de la
compilation

Ce n'est pas la sémantique actuelle de l'inclusion et ce n'est pas
souhaitable car on veut pouvoir gérer des délais de recalcul différents
pour les squelettes incluant et inclus. Encore une fois tu veux nous
faire modifier et la sémantique de SPIP et un énorme morceau du code
pour traiter un soi-disant "problème" extrêmement mineur. Je suis
personnellement fatigué de ce genre d'interventions.

pour l'après, cite moi UNE installation de Spip où le php est installé
comme ça.

Je n'en connais aucune mais le fait est que pour l'instant ça ne gêne
pas, ce qui ne sera pas le cas avec ta proposition.

ciao

Antoine.

11

Autrement dit, tel M. Jourdain, tu utilises Eval sans le savoir
dès que tu inclus un fichier.

Merci de me prendre pour un con.

??? Sache que j'ai beaucoup plus d'estime pour M. Jourdain
que pour son créateur qui se moque des mal-nés qui veulent s'instruire,
moquerie odieuse, réactionnaire et facile.
Mais bon, je veux bien retirer cette maladresse, si tu m'accordes
qu'elle n'est pas pire que de parler de système "couillu"
à une correspondante de cette liste.

Maintenant, ce que tu dis sur eval confirme quand même
que ta vue d'un interprète est superficielle: l'include d'un
fichier et l'eval d'une chaine déclenchent l'exécution de la
même séquence de code dans l'interprète (en particulier la
transformation en byte-code) aucun n'est plus dangereux que l'autre.
Je ne te prends pas pour un con, mais pour qq qui n'a jamais écrit d'interprète;
mais tu as fait d'autres choses très bien que moi je n'ai pas faites.
D'accord ?

Tu peux relire ma phrase ? Je dis qu'eval() peut _gêner_ des
optimisations extérieures.

Là effectivement, j'ai lu trop vite. Mais le problème
est la compilation des squelettes de Spip, qui n'ont
jamais été optimisés par php_accelerator ou autres. Et ça n'aurait
d'ailleurs rien apporté, car le code compilé actuel comporte
des doubles dollars, qui sont une abréviation pour un cas particulier
de ... eval (puisque ça va chercher la valeur d'une variable inconnue à la lecture)
ce qui, comme tu l'as dit, empeche les optimiseurs d'optimiser.
Je suis assez estomaqué que tu rales parce que je conseille de remplacer
include par eval (la seule différence étant dans le gain d'un accès disque en faveur d'eval)
alors que dans le même temps tu te permets le $$ dans ton compilo,
ce qui n'est pas le cas du mien.

Tu n'as pas compris. Le PHP ajouté automatiquement _par SPIP_ ne peut
pas être éliminé de façon générale. C'est tout.

J'ai parfaitement compris, et je soutiens le contraire.
Tu parlais du formulaire_admin dans ton précédent mail, tu peux aller
voir dans mon compilo comment je me suis débrouillé pour le traiter
sans <?php rajouté. Il y a peut-etre des bugs parce que
ce n'est pas facile, certes, mais le principe est universellement applicable.

explique-nous comment tu vas faire pour éviter
que le webmestre envoie ses propres données à l'écran sans informer
SPIP. On en revient toujours au même problème : tu veux que SPIP se
comporte comme si le contenu envoyé à l'écran provenait uniquement des
squelettes, alors que rien ne garantit un tel comportement, à quelque
niveau que ce soit.

J'aimerais que tu répondes à l'objection que j'ai déjà faite:
à partir du moment où Spip génère des headers, c'est qu'il suppose
que personne n'émet en dehors de lui. C'est implicite dans la définition de Spip,
je ne fais qu'officialiser un état de fait, ce qui est toujours une bonne chose.

Encore plus compliqué à traiter : les balises <INCLURE...>.

Le compilateur que j'ai proposé est réentrant car il n'utilise aucune
variable globale:

Et quel est le rapport avec la génération du Content-Length ?? Tu ne
réponds pas au problème.

Je voulais seulement dire que pour cette inclusion de PHP, effectivement
la plus délicate, le calcul du content-length ne posera pas pb.

j'ai déjà fait l'essai de réaliser l'include au moment de la
compilation

Ce n'est pas la sémantique actuelle de l'inclusion et ce n'est pas
souhaitable car on veut pouvoir gérer des délais de recalcul différents
pour les squelettes incluant et inclus.

Je mentionnais une solution parmi d'autres permises par un compilateur réentrant.
Cela dit, ayant aussi travaillé sur la mise à jour automatique des caches,
je ne crois pas que cette possibilité reste utile à terme, et je serais
curieux de savoir s'il existe des sites SPIP où elle est vraiment utilisée.

Encore une fois tu veux nous
faire modifier et la sémantique de SPIP et un énorme morceau du code
pour traiter un soi-disant "problème" extrêmement mineur.

Je ferai remarquer que c'est Fil qui a soulevé le pb des fermetures
de connexion qui doivent attendre la fin d'exécution des scripts.
Mon intervention est seulement de dire que ca ne me semble possible qu'en implémentant
le content-length, et que ceci n'est pas aussi infaisable ou risqué
que tu l'affirmes. Sur l'opportunité de le faire dans votre distribution,
c'est à vous de voir, mais en ce qui me concerne je ne vois que des avantages
et aucun inconvénient.

A+
      Emmanuel

12

Hello,

l'include d'un fichier et l'eval d'une chaine déclenchent
l'exécution de la même séquence de code dans l'interprète (en
particulier la transformation en byte-code) aucun n'est plus
dangereux que l'autre.

Etant un utilisateur occasionnel de eval(), je peux clairement le
déconseiller si une autre solution est envisageable, pour deux
raisons:

- échapper les caractères particuliers des chaines passées à eval(),
  et traiter le coup des délimiteurs de code PHP n'est pas trivial

- trouver un bug dans un code passé à eval() n'est pas une mince
  affaire, loin de là

tu veux que SPIP se comporte comme si le contenu envoyé à l'écran
provenait uniquement des squelettes, alors que rien ne garantit un
tel comportement, à quelque niveau que ce soit.

J'aimerais que tu répondes à l'objection que j'ai déjà faite: à
partir du moment où Spip génère des headers, c'est qu'il suppose que
personne n'émet en dehors de lui.

Rien n'empêche de redéfinir ces headers au sein d'une application qui
inclue des pages générées par SPIP, je le fais.

On peut "écraser" des en-têtes déjà envoyé, sauf si on ne sait pas
quelle valeur donner, donc si je ne connais pas la taille de mon
contenu dans mon appli qui inclue du SPIP, je vais être gêné par un
en-tête Content-length ...

j'ai déjà fait l'essai de réaliser l'include au moment de la
compilation

Ce n'est pas la sémantique actuelle de l'inclusion et ce n'est pas
souhaitable car on veut pouvoir gérer des délais de recalcul
différents pour les squelettes incluant et inclus.

ayant aussi travaillé sur la mise à jour automatique des caches, je
ne crois pas que cette possibilité reste utile à terme, et je serais
curieux de savoir s'il existe des sites SPIP où elle est vraiment
utilisée.

Oui.

-Nicolas

13

Etant un utilisateur occasionnel de eval(), je peux clairement le
déconseiller si une autre solution est envisageable, pour deux
raisons:

- échapper les caractères particuliers des chaines passées à eval(),
  et traiter le coup des délimiteurs de code PHP n'est pas trivial

- trouver un bug dans un code passé à eval() n'est pas une mince
  affaire, loin de là

Merci d'intervenir, les discussions à plusieurs sont toujours plus sereines.

J'ai l'impression que le problème est mal posé car on parlait d'autres choses,
et eval s'est glissé dans le sujet au détour d'un exemple que j'ai donné et qui
aurait pu être autre.

Je précise donc d'abord que je suis moi aussi contre l'utilisation d'eval quand cela est possible, et c'est d'ailleurs pour cela que j'ai éliminé les '$$' dans le compilateur de squelettes. Maintenant le pb précis dont nous parlons est la production de code PHP par ce compilateur, production qui consiste inévitablement en une chaîne.
La version actuelle du compilateur écrit cette chaine dans un fichier (les fameux caches)
puis fait un include de ce fichier. Dans certains cas, en particulier les forums,
ce fichier est immédiatement détruit car aussitot obsolète.
J'affirme que remplacer cette séquence fwrite/include/delete par eval est rigoureusement
identique sur le plan sémantique mais beaucoup plus efficace évidemment.
Je trouve donc absurde ce réflexe d'inquiétude devant Eval et pas devant Include
qui recèle pourtant les mêmes dangers puisqu'il appelle eval implicitement.

J'aimerais que tu répondes à l'objection que j'ai déjà faite: à
partir du moment où Spip génère des headers, c'est qu'il suppose que
personne n'émet en dehors de lui.

Rien n'empêche de redéfinir ces headers au sein d'une application qui
inclue des pages générées par SPIP, je le fais.

On peut "écraser" des en-têtes déjà envoyé, sauf si on ne sait pas
quelle valeur donner, donc si je ne connais pas la taille de mon
contenu dans mon appli qui inclue du SPIP, je vais être gêné par un
en-tête Content-length ...

J'ai bien précisé que je proposais de calculer le content-length seulement
s'il n'y avait pas de '<?php' dans le code retourné par le compilateur,
donc s'il n'y en avait pas dans le squelette compilé. Si ton application
inclue ça autrement, je suis curieux de savoir comment, mais je ferai tout
de suite remarquer que si elle écrase les header déjà envoyés, ce sera aussi le
cas d'un éventuel content-length s'y trouvant.

Ce n'est pas la sémantique actuelle de l'inclusion et ce n'est pas
souhaitable car on veut pouvoir gérer des délais de recalcul
différents pour les squelettes incluant et inclus.

ayant aussi travaillé sur la mise à jour automatique des caches, je
ne crois pas que cette possibilité reste utile à terme, et je serais
curieux de savoir s'il existe des sites SPIP où elle est vraiment
utilisée.

Oui.

Soit. Mais la mise à jour automatique des caches vise à dispenser l'utilisateur
de ces réglages fastidieux.

Encore merci pour ton intervention.

      Emmanuel

14

J'ai l'impression que le problème est mal posé car on parlait
d'autres choses, et eval s'est glissé dans le sujet au détour d'un
exemple que j'ai donné et qui aurait pu être autre.

Certes, mais je répondais sur les différents points évoqués au final.

La version actuelle du compilateur écrit cette chaine dans un
fichier (les fameux caches) puis fait un include de ce fichier.

L'écriture n'est nécessaire de toute façon que pour mise à jour du
cache, donc pas toujours.

Si tu fais un eval plutôt qu'une écriture en fichier, tu n'as plus de
cache.

Dans certains cas, en particulier les forums, ce fichier est
immédiatement détruit car aussitot obsolète.

Il n'est obsolète qu'une fois qu'un nouveau message est posté, pas à
chaque consultation.

J'affirme que remplacer cette séquence fwrite/include/delete par
eval est rigoureusement identique sur le plan sémantique mais
beaucoup plus efficace évidemment.

Sémantique, peut-être, mais pas techniquement.

Je trouve donc absurde ce réflexe d'inquiétude devant Eval et pas
devant Include qui recèle pourtant les mêmes dangers puisqu'il
appelle eval implicitement.

Comme je le disais déjà, il y a pourtant une différence fondamentale,
on n'écrit pas un code à évaluer comme un code à inclure.

Un code à inclure, c'est du PHP à la portée de tout développeur PHP,
c'est connu.

Un code à évaluer, c'est plus sournois, il faut échapper certains
caractères, et faire une manipulation pénible pour réellement
l'évaluer sans soucis, d'autant plus si on utilise l'output buffering,
ce qui est le cas de SPIP.

Rien n'empêche de redéfinir ces headers au sein d'une application
qui inclue des pages générées par SPIP, je le fais.
On peut "écraser" des en-têtes déjà envoyé, sauf si on ne sait pas
quelle valeur donner, donc si je ne connais pas la taille de mon
contenu dans mon appli qui inclue du SPIP, je vais être gêné par un
en-tête Content-length ...

J'ai bien précisé que je proposais de calculer le content-length
seulement s'il n'y avait pas de '<?php' dans le code retourné par le
compilateur, donc s'il n'y en avait pas dans le squelette compilé.

J'ai dis que mon application incluait du contenu retourné par SPIP,
pas l'inverse, mon contenu SPIP ne contient aucun PHP.

Si ton application inclue ça autrement, je suis curieux de savoir
comment

Simple :

<?php
// début de mon appli
...
// Un bout de contenu SPIP
require 'sommaire.php3';
// Suite de mon appli
...
?>

mais je ferai tout de suite remarquer que si elle écrase
les header déjà envoyés, ce sera aussi le cas d'un éventuel
content-length s'y trouvant.

On écrase les headers un par un, selon leur nom ! Je répète donc :

"si je ne connais pas la taille de mon contenu dans mon appli qui
inclue du SPIP, je vais être gêné par un en-tête Content-length"

ayant aussi travaillé sur la mise à jour automatique des caches,
je ne crois pas que cette possibilité reste utile à terme, et je
serais curieux de savoir s'il existe des sites SPIP où elle est
vraiment utilisée.

Oui.

Soit. Mais la mise à jour automatique des caches vise à dispenser
l'utilisateur de ces réglages fastidieux.

Comment peux-tu automatiser quoi que ce soit en terme de réglage de la
durée d'obsolescence de tes contenus ???

-Nicolas

15

Je te propose de lire les contributions que j'ai faites sur spip-contrib,
où figurent la réponse à presque toutes tes questions. La plus récente est:

http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=309

et contient des pointeurs sur les précédentes.
Je précise que j'utilise ma version avec eval depuis un mois sans aucun problème,
et que l'utilisation d'eval à la place d'include y est transparente.

Réécris si cette "réponse" ne suffit pas.

      Emmanuel

16

<quote who='Déesse A.' when='12/01/04 00:27'>

Ce n'est pas la sémantique actuelle de l'inclusion et ce n'est pas
souhaitable car on veut pouvoir gérer des délais de recalcul différents
pour les squelettes incluant et inclus.

Je mentionnais une solution parmi d'autres permises par un compilateur réentrant.
Cela dit, ayant aussi travaillé sur la mise à jour automatique des caches,
je ne crois pas que cette possibilité reste utile à terme, et je serais
curieux de savoir s'il existe des sites SPIP où elle est vraiment utilisée.

J'ai un exemple simple :

- une home mise à jour souvent, qui va chercher pas mal d'informations subalternes (comptage des forums, etc)
- une arbo qui bouge très peu, donc une zone de navigation avec un gros temps de cache (parce que l'arbo est grosse et nous ne souhaitons pas la recalculer aussi souvent que la home)

=> deux temps de calcul réglés différemment, entre le fichier incluant (la home) et le fichier inclus (la barre de navigation)

17

Au cours de la discussion sur le calcul en background,
Nicolas Hoizey a écrit :

mon application incluait du contenu retourné par SPIP

<?php
// début de mon appli
...
// Un bout de contenu SPIP
require 'sommaire.php3';
// Suite de mon appli
...
?>

"si je ne connais pas la taille de mon contenu dans mon appli qui
inclue du SPIP, je vais être gêné par un en-tête Content-length"

N'as-tu pas déjà un problème avec le header "Location" qui est parfois
retourné par Spip ?

      Emmanuel

18

"si je ne connais pas la taille de mon contenu dans mon appli qui
inclue du SPIP, je vais être gêné par un en-tête Content-length"

N'as-tu pas déjà un problème avec le header "Location" qui est
parfois retourné par Spip ?

Je n'en ai pas par ailleurs, et j'utilise l'ouput buffering, donc pas
de soucis, non.

-Nicolas