La javascript sait depuis quelques temps communiquer directement avec un serveur en HTTP :
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
Ca marche sur IE(windows), Safari et Mozilla.
Pour simplifier tout ça, il y a un wrapper PHP :
http://jpspan.sourceforge.net/wiki/doku.php
L'utilisation classique est la complétion dans un champs texte (comme dans gmail).
Ca correspond aux besoins d'interface riche de Spip, non?
M.
J'ai lu le mail de présentation, et j'avoue ne pas avoir tout compris.
Je pensais que ton système ce situait coté serveur, avec du PHP qui cause à du PHP. Une partie interface, une partie modification/traitement de donnée. Le classique MVC.
Peut être qu'un petit schéma permetterait d'éclaircir une idée qui va faire sauter l'interface monolythique de Spip?
M.
@ Mathieu Lecarme <mathieu@garambrogne.net> :
J'ai lu le mail de présentation, et j'avoue ne pas avoir tout compris.
Je pensais que ton système ce situait coté serveur, avec du PHP qui
cause à du PHP. Une partie interface, une partie modification/traitement
de donnée. Le classique MVC.
Oui, la partie importante est côté serveur, l'enregistrement des données.
Mais le client peut parler au serveur de plein de manières différentes.
Peut être qu'un petit schéma permetterait d'éclaircir une idée qui va
faire sauter l'interface monolythique de Spip?
Le plus simple est d'essayer le fichier, c'est tout de suite assez
"évident", ensuite il faut regarder le code et remplir les trous 
Mais, on en discute de préférence sur la liste spip-lab.
-- Fil
Pour simplifier tout ça, il y a un wrapper PHP :
http://jpspan.sourceforge.net/wiki/doku.phpL'utilisation classique est la complétion dans un champs texte (comme
dans gmail).
Dans gmail le javascript ne se connecte pas directement, le fonctionnement
est plus raffiné : il y a deux frames dont une invisible, l'une contient
l'ensemble des fonctions générant l'interface (plusieurs centaines de
kilo-octets de code javascript), l'autre contient les données (aussi en
javascript) renvoyées quand on clique sur un lien.
a+
Antoine.
Oui, je pense comme toi mathieu, que ces techniques vont être de plus en plus utilisé. Même si c'est pas forcément simple à mettre en oeuvre. J'avais déjà un peu essayé de bricoler ça, mais Aïe, y'a pas foule de doc sur le sujet sur le web. Quoique, ça commence.
Quelques liens si tu es intéressé par le sujet :
http://developpeur.journaldunet.com/tutoriel/dht/020319jscript_remotescripting.shtml
http://www.ashleyit.com/rs/main.htm
Et puis tiens, un CMS qui a apparament implémenté quelques bases http://www.blueshoes.org/en/javascript/jsrs/
Enfin, juste pour le plaisir des yeux, il y a un petit moteur de recherche 
qui doit en user. www.a9.com
Les onglets books et images ont un contenu chargé dynamiquement, sans recharger la page, n'est-il pas ? (ça va vite, il y a du serveur derrière)
Oui, je pense comme toi mathieu, que ces techniques vont être de plus en plus utilisé. Même si c'est pas forcément simple à mettre en oeuvre. J'avais déjà un peu essayé de bricoler ça, mais Aïe, y'a pas foule de doc sur le sujet sur le web. Quoique, ça commence.
Quelques liens si tu es intéressé par le sujet :
http://developpeur.journaldunet.com/tutoriel/dht/020319jscript_remotescripting.shtml
http://www.ashleyit.com/rs/main.htm
Et puis tiens, un CMS qui a apparament implémenté quelques bases http://www.blueshoes.org/en/javascript/jsrs/
Enfin, juste pour le plaisir des yeux, il y a un petit moteur de recherche qui doit en user. www.a9.com
Les onglets books et images ont un contenu chargé dynamiquement, sans recharger la page, n'est-il pas ? (ça va vite, il y a du serveur derrière)