Articles précédents : Logiciel
- [50] Privoxy 3.0 est sorti !
- [11] RawWrite ++ : Traduction française
- [8] Netbeans 3.4 est sorti
- [9] Kylix 3 Open version US est disponible.
- [32] Blender bientôt libre !
- [27] JDK 1.4.1 RC ...
- [4] Sortie de KDE 3.1 Beta 1
- [99] Arrêt du développement de XviD
- [14] logiciel de facturation sous Linux
- [3] Lire 1.1 est sorti
Liens connexes
- Télécharger SPIP (1370 hits)
- Documentation (1248 hits)
- Annonce et liste des nouveautés (919 hits)
- Des sites sous SPIP (1818 hits)
- daCode (621 hits)
Dépêche modérée par
Je rajoute un lien vers daCode parce qu'il faut bien faire un peu de lèche, et que le système de modération des forums est génial.
![[fr]](../../../images/fr.png)
Télécharger SPIP (1370 hits)-
Documentation (1248 hits)
-
Annonce et liste des nouveautés (919 hits)
-
Des sites sous SPIP (1818 hits)
-
daCode (621 hits)
> Lire les commentaires (53 commentaires, moyenne: 3,6).
SPIP is good
SPIP est vraiment un super outil. L'interface de gestion des contenus permet de totalement se liberer des problemes de mise en page, surtout quand plusieurs utilisateurs s'occupent de la mise à jour du site.
La personalisation est super facile (heuresement parce que le modèle de base est ... bof!)
-
[^]Re: SPIP is good
Posté par nicolas cartron (page perso, ) le 02/09/2002 à 20:23. (lien). Évalué à 36.Je confirme,
j'utilise la version 1.3.2 pour Squirrelmail-fr.org (http://www.squirrelmail-fr.org(...)).
Et le résultat est plutôt joli, le système de squelettes, mélange de code HTML et de balises SPIP (syntaxe très simples) est très facile à appréhender.
Bravo en tout cas.
Et je trouve plutôt sympa de la part de linuxfr de passer la news (ben oui, SPIP, c'est un concurrent de dacode ! ;)-
[^]Re: SPIP is good
Posté par yves-laurent allaert () le 03/09/2002 à 07:30. (lien). Évalué à 10.d'apres les exemples de sites avec spip, il est impossible de faire comme avec dacode: on ne peux pas reconnaitre que le site a ete fait avec spip du 1er coup d'oeil
-
[+] [^]Re: SPIP is good
Posté par john howard () le 03/09/2002 à 09:20. (lien). Évalué à -2.Mmmhhh je ne pense pas que SPIP soit un concurent de dacode, dans la mesure ou SPIP est un systeme de publication d'articles comprennant egalement un forum alors que dacode est un portail de news ( assez pousse faut dire :) ).
N'empeche, ca aurait pu faire un beau troll dacode vs SPIP, mais j'ai cru voir une news avec windows, on va pouvoir se consoler ;)
-
[+] Petite précision...
(disclaimer: sur suis en mode <NOTROLL>, ne pensez pas le contraire)
"trucNuke" s'appelle en fait PhpNuke (voir http://www.phpnuke.org(...)) et en est à sa version 6.0 je crois. Pour l'avoir utilisé, je pense que SPIP est très adapté pour les petits sites à mettre en place très rapidement, phpnuke quant à lui est assez aussi simple et rapide à mettre en oeuvre mais est plus dédié aux très gros sites multilingues, et il comporte un nombre impressionant de modules aussi divers que variés.
Par contre je ne sais pas s'il y a un système de cache dans phpnuke, ce qui est pourtant un gros atout.
-
[^]Re: Petite précision...
Posté par Pascal Terjan (Jabber id, page perso, ) le 02/09/2002 à 21:20. (lien). Évalué à 12.Sans vouloir trop troller non plus, phpnuke est un nid de trous de sécurité très mal codé. Il ne tient pas du tout la charge pour les gros sites.
Sans compter ce que je pense de son auteur mais je vais éviter de devenir trop méchant.-
[^]Re: Petite précision...
Posté par Guillaume Rousse (page perso, ) le 02/09/2002 à 21:27. (lien). Évalué à 40.>phpnuke est un nid de trous de sécurité très mal codé
Tu veux dire que les trous de sécurité sont mal codés ? Les développeurs ne respectent vraiment plus rien de nos jours :-)
-
[^]Re: Petite précision...
Posté par Éric (Jabber id, page perso, ) le 02/09/2002 à 21:28. (lien). Évalué à 12.<troll>
sisi, phpnuke c'est pour les gros sites.
D'ailleurs n'importe quel site perss devient un gros site niveau ressource si on met phpnuke dessus :)
</troll>
-1 car je vais pas être le seul à le dire
-
[^]Re: Petite précision...
Posté par core () le 02/09/2002 à 22:15. (lien). Évalué à 3.Justement, conscient des trous de sécurité et conscient de la faiblesse de certaines parties du code, son auteur l'a réécrit entièrement, ce qui en fait un très beau morceau de Logiciel Libre, qui tient en outre maintenant admirablement la charge depuis les versions 5.x.
Pour l'anecdote, il faut savoir que F. Burzzi a appris le PHP & le SQL au fur et à mesure qu'il a développé PHPNuke! Pour avoir suivi le code de très près au fil des versions, je peux vous dire qu'il a admirablement progressé :-)-
[^]Heuuuuu
Posté par Moby-Dik () le 02/09/2002 à 23:16. (lien). Évalué à 1.PHPNuke qui tient admirablement la charge ?? Tu veux dire qu'il y a un système de cache maintenant ?
Si ce n'est pas le cas, je ne vois pas comment il pourrait "tenir la charge" pour une page du genre http://www.phpnuke.org/(...) chez un hébergeur bon marché. C'est une simple question de bon sens et de poids en ressources : sur une page d'accueil PHPNuke, il faut une bonne tripotée de requêtes SQL pour afficher toutes les boîboîtes.-
[+] [^]Re: Heuuuuu
Posté par Anonyme () le 03/09/2002 à 11:01. (lien). Évalué à -6.De toutes façons, ni PHP ni Apache (1) sont prévus pour tenir la charge. Comme SPIP et PHPNuke tournent sous PHP, ça règle le problème.
-
[+] [^]Re: Heuuuuu
Posté par Anonyme () le 03/09/2002 à 13:41. (lien). Évalué à -5.Je pourrais savoir pourquoi je me prends plein de [-]? Ce que je dis est vrai: Apache 1 et PHP n'ont JAMAIS été prévus pour tenir la charge et par conséquent ne la tienne pas.
Je parle de vrai charge en test, hein, des trucs du genre 4000 utilisateurs simultanés avec requêtes aux BDD, pas des tests avec ab quoi.-
[+] [^]Re: Heuuuuu
Posté par Moby-Dik () le 03/09/2002 à 13:53. (lien). Évalué à -3.Peut-être qu'ils ne tiennent pas la charge "out of the box". Mais il y a des tas de sites à très fort trafic qui utilisent Apache et/ou PHP.
Et puis ce serait intéressant d'avoir des termes de comparaison avec d'autres solutions.-
[+] [^]Re: Heuuuuu
Posté par Anonyme () le 03/09/2002 à 14:23. (lien). Évalué à -2.Ben ici on a un site a très fort trafic (15M de hits/jours, 4000 utilisateurs simultanés répartis sur 8 serveurs), et on est pas sous Apache.
Les benchs faits étaient plus stressants que la réalité (2 à 3 fois), et Apache plantait lamentablement comme une grosse loutre bourrée à la bière, même customizé à donf les manettes.-
[+] [^]Re: Heuuuuu
Posté par Nicolas Boulay () le 03/09/2002 à 14:30. (lien). Évalué à -1.Fabien t'est pas dans le coin ?
Il m'avait parler du site du festival de Cannes, de mémoire il avait aussi 15M de hits/jour.
(et au fait, personne n'a tester apache+httpd ou apache+Tux, parait qu'en statique les perf font x2-4)
nicO--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: Heuuuuu
Posté par Fabien Penso (Jabber id, page perso, ) le 03/09/2002 à 15:03. (lien). Évalué à 2.Oui, mais on avait des pages statiques, justement parce qu'on ne voulait pas se faire chier.
De toute manière il faut pas chercher, si ce n'est pas des pages statiques alors il faut un max de matos, là nous on tournait sur un bi PPro200...
-
-
-
-
-
-
[^]Re: Heuuuuu
Posté par core () le 03/09/2002 à 13:40. (lien). Évalué à 2.Bien tenir la charge, ça signifie que la complexité des algorithmes mis en oeuvre est _linéaire_ par rapport à la charge, non pas exponentielle (car dans ce cas le serveur ralentit puis s'effondre).
Ce n'est pas parceque tu vas avoir plein de requetes SQL que tu vas forcément avoir une mauvaise tenue à la charge. Ca dépend de la façon dont c'est implémenté.
Le cache est un système (souvent pratique) pour faire encaisser de fortes charges à un serveur, ou à compenser un système qui justement ne tient pas la charge.
Il faut savoir que les systèmes de cache peuvent (au moins) être de deux ordres sur un site Internet :
1) cache HTML des pages : l'utilisateur a "l'impression" d'utiliser un système dynamique mais en fait il visualise le résultat HTML qui est enregistré régulièrement sur le serveur à partir du contenu réellement dynamique PHP<->BD.
-> ce système permet d'éviter d'interpréter le PHP et d'effectuer toutes les requetes SQL à chaque fois qu'une page est interrogée (n'est-ce pas un système similaire qui est implémenté avec DaCode ?)
2) cache SQL : les requetes SQL les plus courantes sont mises en cache, ça évite d'avoir à interroger le système de BD à chaque fois si le résultat est toujours le même, et PHP n'y voit que du feu.
-> ce système économise les ressources bases de données qui sont souvent le principal facteur de charge d'un système web dynamique. Ce système est implémenté par défaut dans certaines bases de données comme Oracle, mais pas dans MySQL par exemple (peut-être dans des versions très récentes ?)-
[+] [^]Re: Heuuuuu
Posté par Moby-Dik () le 03/09/2002 à 13:49. (lien). Évalué à -5.C'est gentil de réciter ta leçon mais je ne vois pas où on pourrait avoir un algo exponentiel dans un système de gestion de contenus. Ou alors c'est que le CMS est une bouse.
Pour le cache : ce qu'on te dit est justement que PHPNuke n'a pas de système de cache et regénère toutes les pages à la volée. Une demi-seconde incompressible pour chaque génération de page. Tu vois le problème ?-
[+] [^]Re: Heuuuuu
Posté par core () le 03/09/2002 à 14:08. (lien). Évalué à -3.> C'est gentil de réciter ta leçon
je ne récite pas ma leçon - je parle d'expérience, de choses que je n'ai pas apprises à l'école et j'explique, je pense que ça peut servir.
> mais je ne vois pas où on
> pourrait avoir un algo exponentiel dans un système de
> gestion de contenus.
Malheureusement si c'est mal programmé c'est le genre de choses qui peut arriver.
> Pour le cache : ce qu'on te dit est justement que PHPNuke > n'a pas de système de cache
Ce qui reste à vérifier pour la version 6.0.
> et regénère toutes les pages à la volée. Une demi-seconde
> incompressible pour chaque génération de page.
C'est totalement faux.
> Tu vois le problème ?
Oui : le pb c'est que tu n'as pas d'expérience de mise en oeuvre de _gros_ sites qui utilisent PHP/SQL et donc que tu parles de ce que tu connais mal.
J'ai monté un certain nombre de sites sur une base phpnuke et avec les versions récentes (5 et +) certains encaissent plus de 100 utilisateurs simultanés pendant plusieurs heures, sans charge extrème du serveur, et avec un temps d'accès inférieur à la seconde.-
[^]Discussion stérile
Posté par Moby-Dik () le 03/09/2002 à 17:03. (lien). Évalué à 2.Ce qui reste à vérifier pour la version 6.0.
Oui, effectivement, cette version n'est pas sortie. Je peux te parler de Windows 2005 aussi, qui soi-disant n'a pas de bug et est super performant. En attendant PHPNuke 5.6, la version actuelle, n'a pas de système de cache.
C'est totalement faux.
Dis, ça t'arrive de poster des affirmations argumentées ? Tu pourrais au moins sortir un bench, des mesures, une URL....
J'ai monté un certain nombre de sites sur une base phpnuke et avec les versions récentes (5 et +) certains encaissent plus de 100 utilisateurs simultanés pendant plusieurs heures, sans charge extrème du serveur, et avec un temps d'accès inférieur à la seconde.
C'est bien, tu as une URL à nous montrer ? Tous les sites de type Nuke que j'ai vus passer ont une tendance facheuse tendance à ramer, et ce d'autant plus qu'ils sont fréquentés. D'ailleurs je ne suis pas le seul à le dire, tu as bien dû voir qu'à peu près tous les intervenants du forum sont de cet avis. Du coup, une utilisation efficace de PHPNuke, on aimerait bien en avoir une preuve :-))
Note qu'un temps d'accès juste "inférieur à la seconde" c'est notoirement insuffisant si tu as plusieurs dizaines de milliers de consultations par jour. Et si toutes tes pages prennent plus d'une demi-seconde à générer et que tu as beaucoup de visites, ton hébergeur va te flinguer.
-
-
-
-
-
-
-
[^]Re: Petite précision...
Posté par Antoine () le 02/09/2002 à 21:28. (lien). Évalué à 9."trucNuke" s'appelle en fait PhpNuke (voir www.phpnuke.org) et en est à sa version 6.0 je crois.
Plus exactement, il y a l'original et une nuée de forks qui s'en sont suivis (et ça continue...). Pour un aperçu de la galaxie des Nuke-like, voir le site http://www.kaintech.net/.(...)
Personnellement si j'avais besoin de fonctionnalités de type communauté, je prendrais plutôt daCode : code propre, système de cache, et système de votes/modération très sympathique. Les *-Nuke pour moi, c'est vraiment la foire aux machins en tout genre, c'est un gigantesque gloubiboulga incontrôlable et préhistorique.-
[^]Re: Petite précision...
Posté par core () le 02/09/2002 à 22:20. (lien). Évalué à 13.Bah il y a phpnuke et le reste... Moi j'utilise beaucoup PHPNuke et je l'adore car le code est très clean depuis quelques versions, très simple à comprendre, astucieux. On s'y retrouve très facilement dans l'arbo du code, dans les thèmes, et ça permet de hacker très vite sans soucis. En plus il y a vraiment plein de langues disponibles, ce dont j'ai souvent besoin, et des centaines de modules créés par une communauté de développeurs très actifs.
A coté de ça je ne suis pas sectaire, je n'ai rien contre DaCode, mais je préfère présenter des arguments, des faits, que de rentrer dans des querelles partisanes sans fondements.
-
mise à jour 1.3.2 --> 1.4.0
Hop, c'est passé tout seul ! Simple décompression de l'archive SPIP, changer les droits en ecriture sur les repertoires data, ecrire, CACHE et IMG et zou. Quand on se connecte sur la partie admin (/admin) Spip propose de migrer la base de donnée de 1.3.2 vers 1.4. Vider le cache et c'est prêt à consommer. Temps de mise à jour : 3 minutes.
L'interface d'admin a d'ailleurs été entierement refaite. Très clean, mieux organisée (plus hierarchisée, présence de raccourcis...) c'est un vrai bonheur.
Mon thème est resté le même après la mise à jour.
Seul truc bizarre, les petits triangles tournants pour ouvrir et fermer les fils de discussion à la suite des articles ont disparus... A chercher.
http://digitalfox.homeip.net/~journal/(...)
Merci aux developpeurs de Spip.
[+] et en Chine ?
système de cache de SPIP
Dans la version 1.3 le system de cache marche comme suit : il y a un appel à une fonction php qui regarde un timeout, si il est expirer il recalcul tout, sinon il va chercher la page en cache.
Donc, une page souvent inchangée sera recalculée (pour rien) plusieurs fois par jour. Une page mis à jour mettra une heure pour apparaitre en ligne à moins d'invalider le cache à la main.
Je ne comprends pas l'interret d'une telle méthode. Pourquoi ne pas générer directement les pages lorsqu'elle sont publié et fournir sur le site publique directement du html statique bien plus rapide que le système d'indirection. Le dynamique n'a à prioris pas d'interret dans ce cas !
Surtout que les forums ont l'air de fonctionner de cette manière. Si quelqu'un pouvait le lever ce mystère.
(sinon le système de template à l'air sympa !)
nicO
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."
-
[^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 10:55. (lien). Évalué à 1.J'ai même pas compris la question. Décidemment, Oracle, ça use...
Le système de cache SPIP est expliqué dans la doc, mais je retrouve plus le lien. D'après ce que je me souviens, tu donnes une durée de vie à ta page avant regénération (une heure, une journée, une minute) selon ce que tu veux qu'elle fasse.
Si une modif intervient sur la page, le cache n'est pas invalidé et la modif sera donc effective à partir du délai.
Par contre, il y a des actions qui invalident le cache. Typiquement, un post dans le forum.-
[^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 11:37. (lien). Évalué à 2.La question est simple et un peu abrupte : pourquoi un système aussi idiot (à prioris) que ces timing ? Pourquoi passer par du php pour accéder aux pages du sites qui sont statiques (dans le sens modifiable que par leur auteur) ?
On perd tellement de perf !
Il semble à prioris super simple de ne regénérer les pages que après un changement (si on veut limiter la taille du cache, on peut avoir besoin d'effacer et de recréer c'est le cas pour dacode qui est customisé pour chaque utilisateur mais pas SPIP).--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[+] [^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 11:43. (lien). Évalué à -1.Faudrait plutôt le demander sur la ML SPIP alors. Cependant, c'est vrai, c'est idiot vu de la modification des articles. Mais il y a aussi la structure du site (les nouveaux articles, les brèves, les sections, etc.). Comment vois-tu le changement dans une page si ce changement est une nouvelle brève, une section créée?
-
[+] [^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 11:52. (lien). Évalué à -1.Si au bout d'un certain temps, tu sais si une page dois être recalculer, je pense que tu dois savoir ce qu'impacte une modification même de la structure du site. Il y a bien une représentation de l'arbre de dépendance des pages qui trainent qq part. Toutes les pages affectés serait remis à jours.
Le must pour éviter les gros coup de bourre serait de détecter les erreurs 404 pour générer les pages manquantes.
création si manquant + effacement si cache trop grand + page accéder en .html = un vrai cache.
[j'ai jamais dis que c'était simple à faire !]--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[+] [^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 12:02. (lien). Évalué à -2.Ce qui est bien quand on discute avec toi, c'est que t'es pas compliqué comme gars ;-)
Et non, il n'y a pas de page de dépendances.-
[^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 12:09. (lien). Évalué à 1.page de dépendance ou lien dans la base de donnée ou n'importe quoi qui décrit la structure du site.
Et pourquoi je serais compliqué ;p Disons que, pour la gestion des erreurs 404, templeete cherche à le faire mais ce n'est pas dis que des gusses comme free.fr l'autorise.
Je suppose qu'un site comme spip n'a pas des Go de pages même si elles sont toutes générées. Donc tout le site gagnerait tellement en perf à être 100% pure statique (facile x10, si j'ai bien suivi). La partie dynamique sert à gérer le site et la partie publique reste statique. On a même pas besoin d'un vrai système de cache (qui gère absence et taille du répertoire).--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[+] [^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 12:34. (lien). Évalué à -1.Avec le cache justement, énormément de requêtes sont servies en statique (enfin, elles ne repassent pas par le générateur, mais uniquement par quelques scripts PHP).
Niveau dépendance, oui, il y a dans la BDD.
AMHA, je trouve SPIP déjà assez compliqué comme ça pour ne pas le modifier sur ce niveau là. Le système fonctionne bien, il pourrait fonctionner mieux, mais peut-être au prix de développements qui ne sont pas nécessaires pour l'instant.-
[+] [^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 12:52. (lien). Évalué à -1.Nan les pages ne sont pas servi comme statique. Il y a quand même un couche de PHP. Or php est très [très] mauvais au parsing.
C'est un test à faire mais entre .html et le cache de SPIP telle qu'il est, on doit pouvoir multiplier les perf par 2 ou 3 mini et voir beaucoup plus.--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: système de cache de SPIP
Posté par Antoine () le 03/09/2002 à 13:05. (lien). Évalué à 3.C'est un test à faire mais entre .html et le cache de SPIP telle qu'il est, on doit pouvoir multiplier les perf par 2 ou 3 mini et voir beaucoup plus.
Exact. Une page en cache sous SPIP prend 10 à 20 ms (mesuré avec ApacheBench). C'est probablement 10 fois plus qu'une page statique.
(désolé de ne pas faire de réponse plus longues, le serveur me jette :-(( )
-
[^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 13:10. (lien). Évalué à 1.Et comment tu fais? Je vois pas comment faire pour servir des pages statiques à partir d'un moteur dynamique? Si ton url se termine par PHP, c'est que c'est du PHP, donc il faut le parser.
-
[^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 13:26. (lien). Évalué à 2.ça c'est sur ;p
Mais en quoi es-tu obliger de mettre ton index en php ?
A mon humble avis, les seul pages à avoir besoin d'être en php sont celle qui perm^te de générer les autres.
En gros, tu accèdes à www.tonsitespip.org/index.html qui propose un lien d'admin vers www.tonsitespip.org/ecrire/index.php pour faire les modifications.
Où est l'interaction des utilisateurs qui nécessitent vraiment un site 100% dynamique ? Même un forum n'a pas d'interret à être 100 % dynamique.--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: système de cache de SPIP
Posté par john howard () le 03/09/2002 à 13:31. (lien). Évalué à 3.A mon humble avis, les seul pages à avoir besoin d'être en php sont celle qui perm^te de générer les autres.
En gros, tu accèdes à www.tonsitespip.org/index.html qui propose un lien d'admin vers www.tonsitespip.org/ecrire/index.php pour faire les modifications.
tout a fait d'accord! Combien de fois suis-je tombe sur des pages web arborant fierement "a ete recode en php". Certaines pages totalement statiques sont "codees" en php, pk donc?-
[^]Re: système de cache de SPIP
Posté par Éric (Jabber id, page perso, ) le 03/09/2002 à 14:37. (lien). Évalué à 0.parce que le jour ou tu voudra rajouter n'importe quoi de dynamique dans la page en question tous les liens peteront.
Si ton site est à 90% des pages php sauf cas bien précis je préfère probablement mettre les 10% restant aussi avec l'extension .php histoire d'etre sur de ne pas etre bloqué dans les évolutions futures. Bon, ca dépend grandement du cas précis mais une page html au milieu de 10 php ca veut dire tout remodifier les liens si tu as besoin de la faire évoluer.-
[^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 14:48. (lien). Évalué à 0.Mais non !
Les pages html sont gérer à 100 % par tes pages dynamiques donc les modifiers est super facile.
La seul différence avec le système actuelle généralement utilisé est de générer la page à la modif et non à la demande.--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."
-
-
-
[^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 13:37. (lien). Évalué à 1.> Où est l'interaction des utilisateurs qui nécessitent vraiment un site 100% dynamique ?
Les forums. Sinon, il y a le cache. Tu vois, je finirais bien par te faire dire que tu es d'accord avec moi, tu y es presque là...
> Même un forum n'a pas d'interret à être 100 % dynamique.
Euh... si. Tu passerai pas un générateur de page HTML au moment du post? En PHP? Sur un serveur multiutilisateur comme un forum Web? Donc conccurent?-
[^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 13:52. (lien). Évalué à 1.Pour le forum (qui représente rarement tout un site), la page de consultation des messages n'a pas besoin d'être dynamique. Seul la page d'ajout ou bien la page appelé après celle d'ajout a besoin d'être dynamique.
--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 14:11. (lien). Évalué à 0.J'aimerai bien voir 1 forum avec une page de consultation en statique, juste pour rigoler.
Tiens, comme ça, une question: comment tu évites qu'en cas de postage simultané, les 2 process qui gèrent ça écrivent en même temps la page de consultation?-
[^]Re: système de cache de SPIP
Posté par Nicolas Boulay () le 03/09/2002 à 14:26. (lien). Évalué à 2.J'ai pas dis de faire n'importe quoi non plus. Tu peux gérer un système de sémaphore. Le premier qui veut écrire le prend, écris sa page, puis le second reprend le semaphore, la modifie et rend le semaphore.
Tu peux aussi ajouter une entrée à une base de donné qui gère ainsi la concurrence. Reste plus qu'à faire un "update" une bète fonction qui transforme BD -> HTMl (en gros le code qui habituellement appeler à chaque requète).
Bref, c'est complexe mais pas bien sorcier. C'est juste une bète partage de ressource.--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: système de cache de SPIP
Posté par Anonyme () le 03/09/2002 à 14:34. (lien). Évalué à 2.Je me doutais que tu allais répondre ça. Je pense que c'est totalement irréalisable dans le principe.
Par contre, le coup de la génération de l'HTML par la BDD ou un process extérieur au serveur Web l'est.
A la limite, même le coup des sémaphores le fichier ça pourrait marcher, mais faudrait pas que ton site ait beaucoup de posts a gérer en même temps.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: système de cache de SPIP (1)
Posté par Antoine () le 03/09/2002 à 13:36. (lien). Évalué à 4.Question de simplicité. Recalculer la page d'article quand un article a changé ne pose pas de problème. Mais imagine :
- il faut aussi recalculer la page consacrée à la rubrique contenant l'article
- il faut éventuellement recalculer la page consacrée à la rubrique parente, si le webmestre y affiche les articles des rubriques filles
- il faut éventuellement recalculer la page des mots-clés liés à l'article, des articles liés aux mots-clés à l'article
- etc.-
[^]Re: système de cache de SPIP (2)
Posté par Antoine () le 03/09/2002 à 13:37. (lien). Évalué à 3.(note : je pose en plusieurs fois, je n'arrive pas à poster de gros messages)
En fait, le problème c'est que ces dépendances ne sont pas figées mais définies par les templates (squelettes) réalisés par le webmestre. Une analyse systématique des dépendances serait trop lourde. On a fait un compromis pour les forums : on y analyse les dépendances les plus communes.-
[^]Re: système de cache de SPIP (2)
Posté par Nicolas Boulay () le 03/09/2002 à 13:52. (lien). Évalué à 3.L'analyse de dépendance ne peut-elle pas être mis à jour à chaque update et utiliser ensuite pour générer ce qu'il faut ?
--
"Tout ce que les être humains font pour contrôler les réseaux informatiques facilite, dans le même temps, le contrôle des êtres humains par les réseaux informatiques."-
[^]Re: système de cache de SPIP (2)
Posté par Antoine () le 03/09/2002 à 13:58. (lien). Évalué à 3.C'est surtout qu'elle serait complexe. Le langage des templates permet d'utiliser des critères grosso modo équivalents à des critères SQL (de type WHERE) pour spécifier quelles données affichées. De plus, SPIP ajoute certains mécanismes particuliers (du genre : une rubrique n'est visible en public que lorsqu'elle contient au moins un article, ou une brève, ou une sous-rubrique elle-même visible...). Ca me paraît particulièrement ardu à traiter, et bonjour les bugs.
-
-
-
SPIP roulèze
Ce qui est appréciable avec SPIP : la syntaxe abstraite, qui permet de faire des articles avec une syntaxe simplifiée, très simple à lire et à écrire.
Résultat : pas de HTML dans les articles, donc on contrôle plus facilement le rendu des articles et l'homogénéité du look. Avantage supplémentaire : on peut envoyer des articles par mail sans avoir à stripper du HTML, mais une syntaxe qu'on maitrise beaucoup plus.
Encore un atout : l'ajout d'images. On uploade, puis on a un tag à mettre dans son article pour insérer l'image...
À noter également : PhpNuke est un weblog avec des modules en pagaille, alors que SPIP est un système de publication en ligne. Pas le même but, même si certains galèrent à vouloir faire des pseudo-gestionnaires de contenu basés sur des Phpnuke-like... Je ne crois pas qu'on puisse retoucher un article après l'avoir écrit, sous PhpNuke, alors qu'avec SPIP c'est possible : les articles appartiennent à des utilisateurs.
-
[+] [^]Re: SPIP roulèze
Posté par Anonyme () le 03/09/2002 à 10:58. (lien). Évalué à -3.> Je ne crois pas qu'on puisse retoucher un article après l'avoir écrit, sous PhpNuke, alors qu'avec SPIP c'est possible : les articles appartiennent à des utilisateurs.
Perdu. Une fois l'article publié, seuls les administrateurs du site peuvent modifier l'article.-
[^]Re: SPIP roulèze
Posté par R4f (page perso, ) le 03/09/2002 à 16:17. (lien). Évalué à 2.> Une fois l'article publié, seuls les administrateurs du site peuvent modifier l'article.
Non, ils peuvent le remettre «en cours d'édition», ce qui nécessite de savoir qui a écrit l'article, et qui est bien plus puissant qu'avec les PhpNuke où on ne sait pas qui a écrit quoi...
-
Cette page a été générée par Templeet en 0.1939s (dont 0.0216 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.