C'est exact. En cas de problème au démarrage, il y a un lien série (via micro-USB) sur le Sheeva, mais ce n'est pas forcément le cas sur toutes, et puis ça nécessite un PC à côté.
D'un autre côté, pour avoir un problème au démarrage, il faut … redémarrer. C'est soit après une coupure d'électricité, soit après une MAJ noyau, donc peu fréquent sur une Debian stable.
Enfin, je ne sais pas comment juger des perspectives de support à long terme des cartes arm. J'ai l'impression que souvent celles-ci sont fournies par leurs fabricants avec des patchs pour le noyau et le boot loader. Qu'en sera-t-il dans cinq ou dix ans? Je n'en sais rien. Quant au X86, je suis à peu près certain que le support s'améliorera avec le temps.
Mon SheevaPlug tourne depuis 3 ans et demi avec une Debian vanilla (le bootloader on ne le touche pas et le noyau est celui de Debian stable (3.2.0-4)). Pour les cartes nues et/ou moins populaires, le support à long terme est peut être plus aléatoire.
Un NAS, c'est l'équivalent d'un PlugComputer (SheevaPlug, dreamplug, cubox, cubox-i…) avec un pool de disques (+ éventuellement du RAID matériel).
Ces ordinateurs-prise ont tous les avantages que tu cites (sauf peut être le bon marché) sans les inconvénients d'un laptop (encombrant, consomme donc chauffe) et tu peux facilement exporter tout ou partie du système avec rsync/cp/ftp/nfs (excepté le bootloader qui est spécifique à la machine) via une carte SD/clé USB et le réimporter sur un système compatible. De plus, la puissance de calcul est largement suffisante pour un serveur de mail et supporte même d'autres services (ssh, web, forge, musique…).
Cerise sur le gâteau : tu peux faire du LVM/RAID en connectant des disques plus importants soit en direct, soit via un hub.
Je trouve dommage d'utiliser de grosses machines énergivores (hormis recyclage) alors qu'on peut faire la même chose avec ce genre de bestioles !
Pour ma part, j'utilise une configuration minimaliste : Apache + Nginx + MPlayer.
Les morceaux sont accessibles depuis le web (simple dossier) et servi par Nginx
Apache permet de les lister de manière "agréable", ainsi que d'afficher la ligne de commande MPlayer qui va bien avec génération automatique de la playlist (contenu de tout le dossier) : ~150 lignes de PHP
MPlayer peut lire les fichiers depuis HTTP/HTTPS
Bien sûr, on est loin de la myriade de fonctionnalités présentes dans les autres serveurs, mais cela permet l'essentiel : lire de la musique distante tout en limitant la charge côté serveur (un petit Sheevaplug). Les seuls défauts sont :
On ne peut pas revenir en arrière dans une playlist
Lorsqu'on fait pause et que le cache se vide, MPlayer passe au morceau suivant
De plus, tu ne vas pas utiliser pwgen (qui n'est pas forcément disponible par défaut sur toutes les plateformes) pour ta/tes clé(s) maître(s), trop compliqué à retenir.
Le générateur intégré est juste une facilité d'utilisation. Quant à l'affichage de la force de la clé maître, c'est une indication pour ne pas avoir un faux sentiment de sécurité parce qu'on aura délégué sa gestion des mots de passes.
C'est marrant de voir qu'on a eu exactement les même problématiques !
Pour le coup, gPass est pas mal en avance sur WKR (interface graphique au top ;), multi comptes, chiffrement uniquement sur le client). Les seules différences sont donc :
WKR est un script multi-navigateur
Gestion hiérarchique des mots de passes
Pour le dernier point, on peut faire "presque" la même chose avec gPass en utilisant plusieurs clés maîtres.
Néanmoins, il reste un point important qui n'est pas traité par WKR : la force des mots de passe. Vu la puissance de calcul disponible sur nos machines, il est important d'inciter les utilisateurs à générer des mots de passes forts (et différents pour chaque compte) autant pour la clé de déverrouillage du trousseau que pour les mots de passes stockés. Pour cela, gPass dispose d'un générateur de mot de passe et de l'affichage de la force de la clé maître (dernier commit en date).
Enfin, il faut trouver le bon compromis entre sécurité et utilisabilité, ce qui n'est jamais évident.
Je me suis inspiré de cette extension (pour l'astuce du @@).
L'avantage est que les mots de passes ne sont stockés nulle part (ni en clair, ni chiffrés), du coup il n'est pas nécessaire de posséder un serveur actif (on peut même les re générer sur leur site, si on n'a pas l'extension installé). Il inclut aussi des contre mesures pour le vol du mot de passe par du javascript vérolé.
L'inconvénient, c'est que l'on ne peut pas décider du mot de passe final (la taille est n+1 par rapport au mot de passe initial). Autre inconvénient : le résultat est encodé en base64, donc pas de caractères spéciaux. L'algorithme utilisé est du hmac_md5.
Un peu de pub, mais pour ceux qui utilisent Firefox, gPass répond à cette problématique, c'est d'ailleurs pour ça qu'il a été crée. Il est actuellement en cours de validation par les équipes de Mozilla pour rejoindre la page des addons.
gPass intègre un générateur aléatoire de mots de passe et, pour maximiser la sécurité, on peut utiliser plusieurs clés maîtres.
Je pense qu'aucune solution n'est parfaite. Il s'agit juste de placer le bon niveau de sécurité par rapport à la facilité d'utilisation. Sécurité est synonyme de contrainte, et quand il y a trop de contraintes il n'y a plus de sécurité (car l'utilisateur fera tout pour se simplifier la vie).
Autre point que j'ai oublié de préciser : on peut utiliser plusieurs clés maîtres pour différents groupes de mots de passes contrairement à lastPass (ou autre) où il n'y a qu'un seul maillon possible.
Le PHP ne fait qu'un ADD/DELETE/GET de valeurs chiffrées (AES-256). On pourrait éventuellement s'interfacer directement avec le SGBD (les bases NoSQL pourraient être une solution à l'avenir, mais c'est moins facile à déployer sur le parc existant).
Comme tout est chiffré côté serveur, on pourrait à priori rendre cette base de données publique.
Les requêtes sont faites par Javascript (comme tout plugin). La clé maître est dérivée via PKDBF2, elle n'est pas stockée.
Il y a un joli schéma ici avec tous les détails techniques d'implémentation (protocole, chiffrement…).
Comme le signale Gof, il est possible d'intercepter la clé maître lors de la saisie. Si c'est un point bloquant, il y a toujours l'interface web pour récupérer les mots de passes en clair.
le plugin en question joue avec le gestionnaire de mots de passes intégré, donc synchronisation automatique via FirefoxSync, mais aussi tous les problèmes liés à ce gestionnaire.
Pour info, l'algo de dérivation utilisé (maison) est une combinaison d'un modulo avec un nombre pseudo aléatoire (hmac(sha1, domain)), ce qui n''est pas très fort d'un point de vue cryptographique.
J'y ai pensé cette nuit. Si le plugin (client) ne reçoit pas "1" comme premier caractère (numéro de version), il affiche une erreur, mais il ne sait pas si c'est une réponse d'un serveur gPass ou autre. Il faudra que je le corrige pour la version suivante.
Je viens de tester avec le xpi dispo dans downloads et le serveur du git, mais je n'ai pas cette erreur. Est-ce que tu as la même configuration ? Tu peux toujours essayer avec le serveur de démo.
Ce n'est effectivement pas "très" compliqué, mais je comprends ce que veux dire Jean-Michel. Il s'agit 1) du support à long terme (multi versions, multi navigateurs) et de 2) de la disponibilité du/des serveurs.
L'idée de lastPass est pas trop mal, c'est une sorte de trousseau de clés en ligne. Il y a toujours le problème de la clé maître, mais en contrepartie il y a un mot de passe par site. Donc, à moins de pirater et décoder la base de lastpass, le hacker ne pourra accéder qu'à un seul compte (et encore s'il arrive à cracker le mot de passe).
J'ai réalisé (en cours de test) une alternative libre et auto hébergée : gPass. Dans ma version, on peut avoir plusieurs clés maîtres. Il n'y a que le plugin pour firefox. Vous noterez les couleurs chatoyantes de la partie serveur, c'est moi qui ai réalisé le design d'iOS 7 !
Il faut voir aussi ce que va donner Ubuntu Touch. Outre la campagne indiegogo pour l'Edge qui finit dans 8 jours (et qui a de fortes chances de ne pas atteindre les 32M$), on va voir débarquer l'OS à partir d'octobre.
ah faut que je regarde ce truc de gzip. C'est le genre de mod que je fais installé par défaut, mais j'avoue ne pas connaitre sont efficacité sur des fichiers minifiés par apport aux coûts cpu de compression.
Le coût CPU est nul puisque la compression est faite lors de la génération et non lors de la requête. Aujourd'hui la majorité des réponses HTTP sont compressées par le serveur.
Au sujet de xml, oui c'est lisible, mais c'est aussi verbeux. Alors autant pour templater de bloc à bloc ça me parait censer, autant pour faire du string replace c'est moi qui bloque.
Mais ce n'est ptet pas le genre de problèmes que tu as eu à résoudre.
Effectivement, le XML est plutôt naturel à utiliser sauf pour la substitution intra chaîne. J'ai donc dû utiliser une petite "astuce". C'est presque bien, mais ce n'est pas ce qu'il y a de mieux comparé aux autres solutions de templates.
Je me posais cette question car je me demandais combien de temps était pris pour générer les commentaires et les impacts sur l’hébergement d'une solution de ce type là.
La génération d'une page avec un nouveau commentaire est plutôt rapide : de l'ordre de quelques secondes (3-5 secondes). Sachant que je suis sur un SheevaPlug auto hébergé, donc assez limité en ressources et bande passante interne (bus, flash, …) et externe.
Stog se distingue par l'utilisation de directives XML et du langage OCaml. Pour le reste, il y a de fortes similitudes avec l'existant (ligne de commande, méta données, Markdown…). Ma solution est plutôt hybride entre application web et site statique.
L'intérêt de ne pas gérer les commentaires localement, c'est que mon site est vraiment entièrement statique, ce qui est au poil pour la sécurité.
Les commentaires et la recherche sont optionnels. Mais je suis d'accord avec toi, il y a potentiellement une faille.
J'ai aussi une balise spéciale pour remplacer une (ou plusieurs) valeur(s) à l'intérieur d'une chaine de caractères : <dyn:replace div_name="img" some_attribute="dyn:blog_id">
Qui donne <img some_attribute="4">
PS : Je n'avais pas fait attention au titre du commentaire, merci :)
Les fichiers (HTML, JS, CSS) sont compressés en gzip, donc ce n'est pas utile.
regroupement
Tout (JS, CSS) dans un fichier ? Si c'est le cas, je préfère avoir des fichiers indépendants qui ne seront téléchargés qu'une seule fois. Néanmoins, je n'utilise qu'un seul JS et qu'une seule CSS.
chargement progressif d'image
Non. Je laisse à nginx le soin d'optimiser ce service.
Quid de la qualité de développement, des impressions, avec ce couple xslt + html ?
Mon blog n'étant pas très complexe, je n'ai pas forcément tous les éléments en main pour comparer. Mais, le gros avantage est que pour la syntaxe, c'est du xml, donc "lisible". Ce que je veux dire, c'est que ce n'est pas une syntaxe exotique.
Le principal point faible est, peut être, un manque de définition forte (règle stricte) des actions des balises : quand j'ajoute quelque chose, c'est que j'en ai besoin.
Par contre un point intéressant, est que j'utilise un système d'inclusion de template (à 1 niveau). Ça permet de faire des modifications rapides et globales (exemple : j'ajoute un élément à mon menu). Je te conseille de regarder le fichier template de base ainsi que le template d'index (qui inclut le template de base).
Sinon en l'état, il y a un point qui me chiffonne tout de même.
L'opération de post de commentaire, le click, est elle complètement chaînée de proche en proche à l'opération de régénération, ou bien le fais tu à intervalle régulier ?
# 0 A.D.
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Civ 5 sous Linux. Évalué à 2.
C'est parce qu'ils ont peur de la concurrence de 0 A.D. !!
[^] # Re: x86 vs Arm
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 1.
C'est exact. En cas de problème au démarrage, il y a un lien série (via micro-USB) sur le Sheeva, mais ce n'est pas forcément le cas sur toutes, et puis ça nécessite un PC à côté.
D'un autre côté, pour avoir un problème au démarrage, il faut … redémarrer. C'est soit après une coupure d'électricité, soit après une MAJ noyau, donc peu fréquent sur une Debian stable.
[^] # Re: x86 vs Arm
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 1.
Mon SheevaPlug tourne depuis 3 ans et demi avec une Debian vanilla (le bootloader on ne le touche pas et le noyau est celui de Debian stable (3.2.0-4)). Pour les cartes nues et/ou moins populaires, le support à long terme est peut être plus aléatoire.
[^] # Re: PlugComputers
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 1.
Problème de rafraîchissement, je n'avais pas vu les derniers messages, désolé.
# PlugComputers
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 1.
Un NAS, c'est l'équivalent d'un PlugComputer (SheevaPlug, dreamplug, cubox, cubox-i…) avec un pool de disques (+ éventuellement du RAID matériel).
Ces ordinateurs-prise ont tous les avantages que tu cites (sauf peut être le bon marché) sans les inconvénients d'un laptop (encombrant, consomme donc chauffe) et tu peux facilement exporter tout ou partie du système avec rsync/cp/ftp/nfs (excepté le bootloader qui est spécifique à la machine) via une carte SD/clé USB et le réimporter sur un système compatible. De plus, la puissance de calcul est largement suffisante pour un serveur de mail et supporte même d'autres services (ssh, web, forge, musique…).
Cerise sur le gâteau : tu peux faire du LVM/RAID en connectant des disques plus importants soit en direct, soit via un hub.
Je trouve dommage d'utiliser de grosses machines énergivores (hormis recyclage) alors qu'on peut faire la même chose avec ce genre de bestioles !
# Serveur de musique à pas cher
Posté par Grégory Soutadé (site web personnel) . En réponse à la dépêche Ampache Doped : Ampache part en fourchette. Évalué à 2.
Pour ma part, j'utilise une configuration minimaliste : Apache + Nginx + MPlayer.
Bien sûr, on est loin de la myriade de fonctionnalités présentes dans les autres serveurs, mais cela permet l'essentiel : lire de la musique distante tout en limitant la charge côté serveur (un petit Sheevaplug). Les seuls défauts sont :
[^] # Re: gPass
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Publication de WKR. Évalué à 1.
C'est "à priori" le problème.
De plus, tu ne vas pas utiliser pwgen (qui n'est pas forcément disponible par défaut sur toutes les plateformes) pour ta/tes clé(s) maître(s), trop compliqué à retenir.
Le générateur intégré est juste une facilité d'utilisation. Quant à l'affichage de la force de la clé maître, c'est une indication pour ne pas avoir un faux sentiment de sécurité parce qu'on aura délégué sa gestion des mots de passes.
# gPass
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Publication de WKR. Évalué à 1.
C'est marrant de voir qu'on a eu exactement les même problématiques !
Pour le coup, gPass est pas mal en avance sur WKR (interface graphique au top ;), multi comptes, chiffrement uniquement sur le client). Les seules différences sont donc :
Pour le dernier point, on peut faire "presque" la même chose avec gPass en utilisant plusieurs clés maîtres.
Néanmoins, il reste un point important qui n'est pas traité par WKR : la force des mots de passe. Vu la puissance de calcul disponible sur nos machines, il est important d'inciter les utilisateurs à générer des mots de passes forts (et différents pour chaque compte) autant pour la clé de déverrouillage du trousseau que pour les mots de passes stockés. Pour cela, gPass dispose d'un générateur de mot de passe et de l'affichage de la force de la clé maître (dernier commit en date).
Enfin, il faut trouver le bon compromis entre sécurité et utilisabilité, ce qui n'est jamais évident.
Bonne continuation.
[^] # Re: gPass
Posté par Grégory Soutadé (site web personnel) . En réponse au journal mot de passe, les sites libristes à la traine.. Évalué à 2.
Je me suis inspiré de cette extension (pour l'astuce du @@).
L'avantage est que les mots de passes ne sont stockés nulle part (ni en clair, ni chiffrés), du coup il n'est pas nécessaire de posséder un serveur actif (on peut même les re générer sur leur site, si on n'a pas l'extension installé). Il inclut aussi des contre mesures pour le vol du mot de passe par du javascript vérolé.
L'inconvénient, c'est que l'on ne peut pas décider du mot de passe final (la taille est n+1 par rapport au mot de passe initial). Autre inconvénient : le résultat est encodé en base64, donc pas de caractères spéciaux. L'algorithme utilisé est du hmac_md5.
# gPass
Posté par Grégory Soutadé (site web personnel) . En réponse au journal mot de passe, les sites libristes à la traine.. Évalué à 6.
Un peu de pub, mais pour ceux qui utilisent Firefox, gPass répond à cette problématique, c'est d'ailleurs pour ça qu'il a été crée. Il est actuellement en cours de validation par les équipes de Mozilla pour rejoindre la page des addons.
gPass intègre un générateur aléatoire de mots de passe et, pour maximiser la sécurité, on peut utiliser plusieurs clés maîtres.
[^] # Re: Excellente initiative !
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
Je pense qu'aucune solution n'est parfaite. Il s'agit juste de placer le bon niveau de sécurité par rapport à la facilité d'utilisation. Sécurité est synonyme de contrainte, et quand il y a trop de contraintes il n'y a plus de sécurité (car l'utilisateur fera tout pour se simplifier la vie).
Autre point que j'ai oublié de préciser : on peut utiliser plusieurs clés maîtres pour différents groupes de mots de passes contrairement à lastPass (ou autre) où il n'y a qu'un seul maillon possible.
[^] # Re: Excellente initiative !
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
Le PHP ne fait qu'un ADD/DELETE/GET de valeurs chiffrées (AES-256). On pourrait éventuellement s'interfacer directement avec le SGBD (les bases NoSQL pourraient être une solution à l'avenir, mais c'est moins facile à déployer sur le parc existant).
Comme tout est chiffré côté serveur, on pourrait à priori rendre cette base de données publique.
Les requêtes sont faites par Javascript (comme tout plugin). La clé maître est dérivée via PKDBF2, elle n'est pas stockée.
Il y a un joli schéma ici avec tous les détails techniques d'implémentation (protocole, chiffrement…).
Comme le signale Gof, il est possible d'intercepter la clé maître lors de la saisie. Si c'est un point bloquant, il y a toujours l'interface web pour récupérer les mots de passes en clair.
[^] # Re: outils de génération de mot de passe ?
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
le plugin en question joue avec le gestionnaire de mots de passes intégré, donc synchronisation automatique via FirefoxSync, mais aussi tous les problèmes liés à ce gestionnaire.
Pour info, l'algo de dérivation utilisé (maison) est une combinaison d'un modulo avec un nombre pseudo aléatoire (hmac(sha1, domain)), ce qui n''est pas très fort d'un point de vue cryptographique.
[^] # Re: Et c’est résolu !
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
J'y ai pensé cette nuit. Si le plugin (client) ne reçoit pas "1" comme premier caractère (numéro de version), il affiche une erreur, mais il ne sait pas si c'est une réponse d'un serveur gPass ou autre. Il faudra que je le corrige pour la version suivante.
[^] # Re: Chez moi, Ça ne marche pas
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
Je viens de tester avec le xpi dispo dans downloads et le serveur du git, mais je n'ai pas cette erreur. Est-ce que tu as la même configuration ? Tu peux toujours essayer avec le serveur de démo.
[^] # Re: Sécurité
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
Exact. L'optique initiale était surtout de ne pas faire confiance aux sites tiers au cas où ils se font hacker.
Comme je l'ai dit plus haut, on peut toujours passer par l'interface web pour récupérer manuellement le mot de passe.
[^] # Re: Excellente initiative !
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 1.
1) Un bookmarklet c'est plutôt limité vu le code Javascript à exécuter, ça pourrait éventuellement être une solution en téléchargeant du code externe
2) Ce n'est pas "compliqué", il faut juste y mettre les moyens. Les gars de lastPass font ça à plein temps, si mon serveur tombe je suis bien embêté…
Autre avantage de ma solution : on peut accéder au trousseau via la page web, donc sans plugin.
[^] # Re: Excellente initiative !
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 3.
Ce n'est effectivement pas "très" compliqué, mais je comprends ce que veux dire Jean-Michel. Il s'agit 1) du support à long terme (multi versions, multi navigateurs) et de 2) de la disponibilité du/des serveurs.
L'avantage ici est que le secret est distribué.
[^] # Re: Lien vers la démo
Posté par Grégory Soutadé (site web personnel) . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 2.
Merci, je me suis trompé quand j'ai recopié le liens !
# lastPass
Posté par Grégory Soutadé (site web personnel) . En réponse au journal La proche fin des mots de passe. Évalué à 3.
L'idée de lastPass est pas trop mal, c'est une sorte de trousseau de clés en ligne. Il y a toujours le problème de la clé maître, mais en contrepartie il y a un mot de passe par site. Donc, à moins de pirater et décoder la base de lastpass, le hacker ne pourra accéder qu'à un seul compte (et encore s'il arrive à cracker le mot de passe).
J'ai réalisé (en cours de test) une alternative libre et auto hébergée : gPass. Dans ma version, on peut avoir plusieurs clés maîtres. Il n'y a que le plugin pour firefox. Vous noterez les couleurs chatoyantes de la partie serveur, c'est moi qui ai réalisé le design d'iOS 7 !
# Ubuntu Touch
Posté par Grégory Soutadé (site web personnel) . En réponse au journal L'avenir de la telephonie mobile ?. Évalué à 1.
Il faut voir aussi ce que va donner Ubuntu Touch. Outre la campagne indiegogo pour l'Edge qui finit dans 8 jours (et qui a de fortes chances de ne pas atteindre les 32M$), on va voir débarquer l'OS à partir d'octobre.
[^] # Re: j'aimes beaucoup ta solution
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Dynastie 0.1. Évalué à 1.
Le coût CPU est nul puisque la compression est faite lors de la génération et non lors de la requête. Aujourd'hui la majorité des réponses HTTP sont compressées par le serveur.
Effectivement, le XML est plutôt naturel à utiliser sauf pour la substitution intra chaîne. J'ai donc dû utiliser une petite "astuce". C'est presque bien, mais ce n'est pas ce qu'il y a de mieux comparé aux autres solutions de templates.
La génération d'une page avec un nouveau commentaire est plutôt rapide : de l'ordre de quelques secondes (3-5 secondes). Sachant que je suis sur un SheevaPlug auto hébergé, donc assez limité en ressources et bande passante interne (bus, flash, …) et externe.
[^] # Re: Dans le même genre : Stog
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Dynastie 0.1. Évalué à 1.
Stog se distingue par l'utilisation de directives XML et du langage OCaml. Pour le reste, il y a de fortes similitudes avec l'existant (ligne de commande, méta données, Markdown…). Ma solution est plutôt hybride entre application web et site statique.
[^] # Re: j'aimes beaucoup ta solution
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Dynastie 0.1. Évalué à 1.
J'ai aussi une balise spéciale pour remplacer une (ou plusieurs) valeur(s) à l'intérieur d'une chaine de caractères :
<dyn:replace div_name="img" some_attribute="dyn:blog_id">Qui donne
<img some_attribute="4">PS : Je n'avais pas fait attention au titre du commentaire, merci :)
[^] # Re: j'aimes beaucoup ta solution
Posté par Grégory Soutadé (site web personnel) . En réponse au journal Dynastie 0.1. Évalué à 1.
Salut,
Dans l'ordre :
Les fichiers (HTML, JS, CSS) sont compressés en gzip, donc ce n'est pas utile.
Tout (JS, CSS) dans un fichier ? Si c'est le cas, je préfère avoir des fichiers indépendants qui ne seront téléchargés qu'une seule fois. Néanmoins, je n'utilise qu'un seul JS et qu'une seule CSS.
Non. Je laisse à nginx le soin d'optimiser ce service.
Mon blog n'étant pas très complexe, je n'ai pas forcément tous les éléments en main pour comparer. Mais, le gros avantage est que pour la syntaxe, c'est du xml, donc "lisible". Ce que je veux dire, c'est que ce n'est pas une syntaxe exotique.
Le principal point faible est, peut être, un manque de définition forte (règle stricte) des actions des balises : quand j'ajoute quelque chose, c'est que j'en ai besoin.
Par contre un point intéressant, est que j'utilise un système d'inclusion de template (à 1 niveau). Ça permet de faire des modifications rapides et globales (exemple : j'ajoute un élément à mon menu). Je te conseille de regarder le fichier template de base ainsi que le template d'index (qui inclut le template de base).
C'est une opération à la demande.