- #HTTP_HEADER{Chose: valeur} qui insère un entete dans le tableau $page[entetes] (ceci toujours via le hack d'insertion de la sequence <?php header(...) ?> dans le code, qui est ensuite nettoyée)
- #CACHE{delai} qui fixe la durée du fichier cache.

A noter qu'on peut mixer les deux de façon parfois étonnante comme sur le login, où le fichier est mis en cache côté spip, mais pas côté navigateur

corrige le bug qui s'était glissé sous #LOGO_xxxxx et qui faisait que le premier filtre donné après || était jeté à la poubelle
L'origine du bug : un décalage entre $p->fonctions et $p->param pour le filtre "vide" (celui qui est entre les deux pipes de ||)

D'accord, c'est toujours plus propre d'initialiser un tableau, mais  PHP 4.4.0 semble bien le seul a ne pas faire de $doublons_index un tableau de 1 element dans cette expression certes inelegante mais licite:
 
calcul_mysql_in('documents.id_document', "0".$doublons[$doublons_index[]= ('documents' . '')], 'NOT')

attention, actuellement la balise #HTTP doit etre utilisee une fois et une seule et en tout debut de squelette; c'est a ameliorer mais ne pas faire croire a mieux en attendant

cache-client std pour les admin afin qu'ils soient traites comme les autres; ils savent comment contrer s'il y a vraiment besoin

probleme de restauration longue. ne pas passer par l'affichage du bandeau (Cedric). A controler soigneusement

passage en squelette du ci-devant ecrire/spip_style.php3. Un peu lourd encore comme ecriture, mais le resultat part en cache.

attention, il y avait encore un appel spip_action sur 'style' et ca fait tres mal avec la nouveau declenchement de restauration. Mais il faudra trouver autre chose que cette insertion en bloc: les pages deviennent enormes a chaque fois

Le script de restauration n'etait pas vraiment surchargeable car la fonction import_all_dist se contentait de faire l'authentification ftp, et declenchait une redirection provoquant l'appel d'une fonction import_init non surchargeable dans ce seul contexte. A present, c'est a nouveau import_all qui est appelee et elle s'apercoit qu'elle a deja authentifie, donc passe a la suite.

Cette strategie fait migrer dans le script central le test (auparavant dans le script d'accueil), d'une restauration interrompue,  mais c'est plus logique.

dans le squelette la duree de vie des pages qu'il produit. 

A la base, c'est la requete HTTP, "Cache-control: max-age = NNNN".

Elle est produite par une extension de la balise HTTP au cas #HTTP{NNNN}.

Les squelettes standards l'utilisent systematiquement.

Nouvelle interface avec les fonctions du cache, pour pouvoir eventuellement decide de la perennite d'un cache sur la base de son contenu

Faciliter l'envoi d'en-tetes http dans les squelettes, afin de remplacer les variables PHP $flag_preserver et $flag_dynamique par des entitees independantes du langage d'execution. Pour cela: 

- introduction d'une balise #HTTP{e1, ... en} utilisable en debut de squelette, et dont les arguments sont des chaines, entourees de guillemets ou d'apostrophes, conforme au protocole HTTP1/1 :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

- cette balise est compilee en une sequence
<?php header(e1); .... ;header(en) ?>

- Spip repere une telle sequence initiale (c'est donc valable aussi pour un code php ecrit directement sous-reserve que la syntaxe soit exactement la meme) et en fait une meta-donnee pour chaque page produite par l'execution du squelette, afin de disposer facilement des en-tetes au moment de l'envoi;

- Spip repere dans ces meta-donnees la presence de la directive Content-Type. Si elle est absente, elle est automatiquement rajoutee avec comme habituellement la valeur:
	Content-Type: text/html; charset=#CHARSET
Spip n'enverra les boutons d'administration et de previsualisation et n'inserera leur CSS associee que si cette directive a pour valeur text/html ou que le mode debug est actif. 
Cette assertion simple reflete l'usage de la variable $flag_preserver qui n'a ainsi plus de raison d'etre.

- Spip repere aussi dans ces meta-donnees la presence d'une directive "Cache-control", auquel cas il n'enverra aucune autre directive concernant le cache du client. Ainsi, le positionnement a "vrai" de la variable $flag_dynamique, jamais documentee, est equivalent a
	#HTTP{'Pragma: no-cache', 'Cache-Control: no-cache; must-revalidate'}

quand on faisait <INCLURE(xxx)> sans aucun contexte, ça prenait le contexte de l'URI, et on perdait le bénéf du cache !