wismerhill a écrit 2608 commentaires

Tu n'es jamais assuré que le fichier n'a pas été modifié avant de relancer le serveur donc ton serveur doit vérifier le fichier.

Si tu as un serveur dont les fichiers de configuration sont modifiés sans te prévenir, il faut t'inquiéter de la sécurité de celui-ci.

La validation qu'a priori est une erreur et dans la conception de site web, amène a de grave erreur si on ne vérifie pas sur le serveur tous les paramêtres POST et GET.

Uh??
On parle de fichiers de configuration là!

Ce n'est pas ton problème, toi tu es utilisateurs, tout cela est programmé / scripté.

Non, tu n'es pas utilisateur, tu es administrateur et tu es supposé comprendre ce que tu utilise.
Si tu es un simple utilisateur, tu aura une interface qui va te proposer des choix plus ou moins simples et se chargera d'écrire un fichier de configuration correct (on espère...). Et là le format exact du fichier tu t'en fous.

Ensuite, je veux un éditeur sans X-Window. Je ne veux pas de l'erreur de Windows d'imposer le graphique sur les serveurs.

Pourquoi parle-tu de X-window?
On peut faire des programmes de validation en console, par exemple xmllint.

Et puis, je ne vois pas pourquoi on ne pourrait pas complèter du YAML puisque ce n'est qu'une autre manière d'écrire un arbre...

C'est sûrement possible de le faire, mais je réagissait sur le fait de valider, non seulement la syntaxe mais aussi le contenu d'un document.

Y a-t-il en YAML un équivalent des schémas XML?

Il est trivial de faire yaml2xml donc valider un yaml est facile...

Si ta proposition pour valider du YAML est de passer par du XML, je préfère utiliser directement du XML avec un éditeur qui le fait à l'édition grâce au schéma/DTD et me propose une complétion automatique.

Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.

Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !

Ben, je trouve ça beaucoup mieux de valider la configuration à priori, plutôt que de relancer son serveur en espérant que tout est bon.
cf "apachectl configtest"

En gros le (x)html écrit par un humain peut s'avérer relativement lisible, car l'humain en question va s'arranger pour placer judicieusement des retours à la ligne et indentations qui rendront la structure du document compréhensible.

Ben, c'est le cas du XML en général.
Il n'y a que pour les éléments qui sont définis avec l'attribut (hérité) xml:space="preserve" qu'il faut faire attention à ses espaces/retours à la ligne.
En général, un document XML offre plus de possibilités de mise en forme car on met à la ligne ce qu'on veut, indépendamment de la structure logique du document.

Mais je concède sans problème que, ne connaissant pas YAML, les documents semblent effectivement tout à fait compréhensibles.

Justement pas!
Prend un peu le temps de lire mon commentaire, ej répondais à sa remarque disant qu'on s'en branle d'avoir un système fonctionnel sans interface graphique ni moteur html.

(bon, OK, un petit links est utile sur certains serveurs)

Non, les calculatrices on s'en fout, elles ne changent pas notre façon de consommer (2 + 2 fait toujours 2, quelle que soit la calculatrice).

Tu devrais regarder du côté de la concurrence pour une calculatrice, je pense que ça changera ta façon de consommer ;-)

N'importe quel distribution linux peu tourner sans moteur html, et même sans serveur graphique, et continuer de fournir un système opérationnel avec des milliers d'applications et leur documentation (man) respective, le tout pouvant être mis à jour en une commande.
'
et honnetement, a par pour de l'embarque on s'en branle....

Ben moi, pour tous les serveurs que j'ai installé j'en suis bien content!

Moi je pleure quand desinstaller un logiciel par defaut sur kde et gnome m'enleve tout kde ou gnome, alors que ce logiciel par defaut et un jeu ou un logiciel de mail, qui sont quand meme moins utile qu'un navigateur web.

Faut utiliser une distribution qui faire ses paquets correctement.

Non, le gestionnaire de fenêtres gère les ... fenêtres.
Il ne s'occupe pas (et ne saurais pas s'occuper) des composants dans les fenêtres, c'est le domaine du programme et c'est lui qui détermine comment ces composants doivent se comporter au-delà du fonctionnement par défaut du toolkit.
Alors peut-être que le toolkit de macOS pourrait par défaut permettre de passer sur tous les composants, mais si le programmeur ne se soucie pas du tout de cet aspect, tu passera sur les composants dans l'ordre où ils auront été ajoutés (ou dans l'ordre où le toolkit les aura trié) ce qui risque de ne pas être pratique.

Ou pour pouvoir inclure des images?
Une capture d'écran ou un petit schéma c'est souvent utile dans une documentation, et ni man ni texinfo n'est prévu pour.

Bridés par rapport à quoi?

Ça t'avancerait à quoi d'avoir tes extension adblock ou youtube (pour prendre des exemples connus) pour visualiser de la documentation?

C'est vrai que certains petits trucs peuvent être utiles, comme pouvoir adapter la taille des polices, mais la majorité des fonctionnalités d'un navigateur web ne sert à rien pour de l'affichage de documentation.

Autre cas d'utilisation: un système d'assistant (wizard). Il est tout à fait intéressant d'avoir, dans les fenêtres successives, des explications mises en forme, avec images mais sans interactivité (éventuellement des liens pour renvoyer vers une doc plus complète). Ça a tout à fait du sens d'intégrer un moteur de rendu HTML dans ces fenêtre plutôt que de se prendre la tête par programmation de gérer des composants graphiques pour faire une mise en forme bancale (et ne parlons même pas des traductions).

Tu donnes des cas ou effectivement, le logiciel travaille sur un canvas HTML pour en modifier de manière interactive le DOM. Dans ces cas là, la liaison sur un moteur est normale.

C'est nullement le cas des programmes d'aide.


Manipuler le DOM, peut-être pas.
Par contre s'interfacer avec les ouvertures d'URL pour pouvoir générer dynamiquement des pages et coupler le tout avec un moteur d'indexation c'est exactement ce dont un navigateur d'aide à besoin, et qui ne serait pas faisable en ouvrant simplement un navigateur web.

Ce qui n'est pas normal, c'est que plein de programmes différents y aillent de leur implémentation d'un navigateur d'aide. Les programmes KDE (avec le khelpcenter) et Gnome (avec yelp) ont justement leurs navigateurs d'aides communs qu'ils peuvent lancer dans un programme à part.

Quand au problème du fichier temporaire, c'est un faux problème, un navigateur devrait ouvrir un page en lisant l'entrée standard. Quand on sais ce que met un navigateur dans son cache, cela me semble aussi un exemple mal choisis...

Je ne suis pas d'accord, je trouve justement que les programmes actuels utilisent beaucoup trop le disque dur, d'ailleurs mon konqueror est configuré avec la cache désactivée pour limiter la quantité d'IO du système.
Donc éviter de lancer un gros navigateur plein de fonctionnalités dans tous les sens juste pour afficher un peu d'HTML me semble une bonne chose (en terme d'IO et en terme de consommation mémoire).

Ce n'est pas aussi simple.
Si le but est juste de lancer un autre programme (dont tu espère) qui va affiche de l'HTML il suffit effectivement d'avoir son nom dans une variable d'environnement.

Si tu veux intégrer un rendu HTML dans ton programme (par exemple client mail ou afficheur d'aide) il vaut déjà mieux avoir une API (éventuellement minimaliste) pour le faire facilement, parce que l'intégration d'une fenêtre X dans une autre n'est pas une technique triviale et donne des résultats peu satisfaisants pour des trucs plus complexes qu'une vidéo.
Pareil si tu as ton HTML à afficher en mémoire (par exemple parce que tu l'as généré toi-même) et que tu veux éviter de devoir l'enregistrer dans un endroit temporaire pour qu'un autre programme puisse le lire (et si on ferme le programme d'origine avant le browser, doit-il supprimer le fichier peut-être encore utilisé, ou le laisser traîner?).

Il y a enfin le cas, plus particulier, des programmes qui ont besoin de s'intégrer intimement avec le moteur de rendu et le DOM de celui-ci. Typiquement les programme d'édition HTML, pas si rares que ça car beaucoup de clients mails proposent l'édition de mails en HTML.

Ça arrive avec l'intégration de policykit dans KDE 4.3.

Les développeurs de KDE ont décidé de ne pas faire une solution bancale à la va-vite et d'attendre une intégration correcte de policykit pour gérer les permissions plus proprement.

Ça c'est uniquement pour que le groupe soit hérité, ça n'impose pas les permissions des nouveaux fichiers.

En python, les parenthèses ont priorité sur l'indentation, il est donc tout à fait possible de choisir son indentation au sein d'un appel de fonction, de l'écriture d'une chaine, de tests etc.

Ah, ça je ne savais pas, merci.
(mon expérience de python date déjà de plusieurs années, je me suis concentré sur java pour raison professionnelle)

Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...

Ça ce sont les programmeurs qui appliquent sans réfléchir les consignes qu'ils ont eu a l'école, et pas que pour les commentaires!
On en a eu un comme ça pendant un moment, c'est toujours un petit éclat de rire, suivit d'un long soupir, de devoir reprendre (réécrire) son code.

Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).


Si ton code doit tourner sur python 2.3 alors il faut développer avec un 2.3!
C'est normal que les API évolue et il ne faut pas t'attendre à ce que tout ce que tu développe avec un 2.5 fonctionne sur un 2.3.

On a parfois le problème au boulot, avec java, on a forcément une version un peu récente par défaut sur nos machines avec d'autres versions à côté pour les développements qui doivent rester compatibles 1.4, mais parfois un des développeurs oublie sur quel JDK il est et on constate plus tard qu'on a des fonctions du 1.5 qui sont utilisées.
Heureusement maintenant on est passé à retrotranslator qui nous permet quand même d'utiliser les améliorations les plus fondamentales de l'API java 1.5.

Justement, tu fais des proportions qui n'ont pas lieu d'être.
L'enrobage syntaxique à la C++ de java fait que des très petits programmes vont faire beaucoup de ligne pour pas grand chose (mais contrairement à python on peut tout mettre sur une seule ligne ;-) )

De plus, je préfère écrire quelques lignes de plus et que le code soit plus lisible plutôt que d'avoir un truc super compact qu'il faut relire cinq fois pour comprendre ce qu'il fait. Mais là je pense plutôt à perl.
Et python, qui impose syntaxiquement l'indentation m'empêche certaine mise en forme du code qui en améliore la lisibilité (séparer un long appel de fonction sur plusieurs lignes avec indentation variable pour bien identifier des groupes de paramètres par exemple)

Et si tu pense qu'on peut faire un projet de taille raisonnable en quick and dirty, je plains ceux qui devront reprendre ton code.

* créer un objet URL et un objet "BufferedInputStream". En python, je gère un seul objet, "session HTTP". "Buffer" ? "Stream" ? Concepts beaucoup trop bas niveau pour ce que je veux faire, morbleu !
* De même, pour l’écriture, tu es obligé de créer un FileOutputStream ET un BufferedOutputStream par dessus. Pour la concision, on repassera.


Non, tu n'es pas obligé, tu peux te contenter de l'InputStream de l'URL et du FileOutputStream, mais c'est plus efficace de bufferiser les IO.

Idem pour la clareté et la simplicité. Pour écrire dans un fichier, c’est trois classes donc: OutputStream, BufferedOutputStream et FileOutputStream. Même si c’était aussi concis que python au niveau du nombre de caractères, ça ne l’est pas au niveau de la doc à consulter.

L'OutputStream c'est juste parce que c'est la classe de base et que j'ai l'habitude ne ne pas utiliser les sous-classes quand je peux me contenter de la classe parente, tu peux écrire directement BufferedOutputStream si ça te dérange tant que ça d'avoir des noms de classe différents.

* Obligé de te taper une boucle pour faire le transfert. Effectivement, tu fais ça en une seule ligne, mais bon…

Dans la méthode python cette boucle est sous-entendue. Au boulot dans un projet de relativement grosse taille on a une méthode utilitaire qui fait ça, on lui passe un InputStream et un OutputStream (ou directement des fichiers ou URLs, y a plusieurs variantes) et elle boucle pour copier l'un dans l'autre.

Ça semble négligeable, dit comme ça. Mais supposons que je veuille en fait remplacer tous les "spam" par des "egg" dans mon texte (oui, supposons que ce soit pas un pdf). En Python, je remplace response.read() par response.read().replace("spam", "egg"). En Java ? Je dois alors m’amuser avec les StreamReader, les convertions byte[]/String… Ajoute une expression régulière, et la différence python/java devient évidente.

Mais donc dans ton exemple tu va charger tout le contenu de ton URL dans une chaîne de caractères pour pouvoir ensuite faire un remplace dessus et puis la réenregistrer, tu va utiliser beaucoup plus de mémoire que nécessaire par rapport à un fonctionnement en streaming.

Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.

> > mes try{}finally{} le rendent plus robuste
> d'accord avec ça le problème que ça me pose c'est que tu es obligé de les mettre...

Bien sur qu'on est obligé de les mettre, l'interpréteur/compilateur ne peut pas trouver de lui-même quelle est la façon intelligente de le faire. (Dans les cas simple comme ici ce serait possible, mais pas en général)

En effet, je me contentais de donner un exemple de code équivalent au code python (enfin, pas tout à fait équivalent, les try{}finally{} le rendent plus robuste en garantissant la fermeture propre des flux).
Mais je considère effectivement que java est plus adapté à des programmes de taille moyenne à grande bien architecturés, pas pour des petits programmes quick and dirty. Pour ce genre de cas je préfère le shell mariné de grep sed awk et autres commandes facilement scriptables ;-)


- des catchs parce que le finally seul ne semble pas plaire à mon compilo java C'est d'ailleurs très bien que Java force la gestion des erreurs mais c'est précisemment ce que j'aime éviter de faire quand je prototype


Non, soit tu intercepte les exceptions (et tu en fait quelque chose), soit tu déclare que ta méthode peut les lancer, en l'occurrence ton main.

Ou même GNU/Hurd!

Allez, le vendredi se rapproche...

En java tu peux faire:


java.io.InputStream is=new java.io.BufferedInputStream(new java.net.URL("http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
try{
java.io.OutputStream os=new java.io.BufferedOutputStream(new java.io.FileOutputStream("what_is_dtest.pdf"));
try{
int c;
while(c=is.read()>=0){os.write(c);}
os.flush();
}finally{fos.close();}
}finally{is.close();}


SUN essaie de relancer l'intérêt de java (la plateforme, pas le langage) pour les contenus web et comme concurrent de flash avec son javaFX:
http://www.javafx.com/

Pour le moment il faut encore programmer pour animer les trucs, mais ils prévoient à court terme (quelques mois) un éditeur visuel.
Le langage javaFX en lui-même est assez différent de java, mais peut utiliser toute la bibliothèque standard java s'il le souhaite. javaFX a ses propres composants graphiques et peut aussi intégrer des composants swing (le contraire n'est pas encore possible, mais devrait arriver car c'est très demandé).

Vu ce que tu décrit, il me semble que tu tente de réécrire en javascript tout ce que fait le navigateur (y compris le head de la page!) quand on clique sur un lien et qu'il charge la page.
Mieux vaut le laisser faire, il le fera bien mieux.
Si tu veux absolument que ce soit fait par javascript t'as qu'à lui demander de charger une nouvelle adresse.

C'est là que la transparence réseau de X tombe à point, j'ai installé un oracle sur un serveur sans interface graphique via une connexion ssh qui déportait l'affichage sur ma machine.
Sinon, dans le même ordre d'idée un serveur VNC sur le serveur peut faire l'affaire, ça évite de devoir se déplacer jusqu'au serveur.

J'ai jamais testé la version entreprise, mais dans la mandriva normale le centre de contrôle mandriva (drakconf) fonctionne aussi en mode texte, on n'a pas toutes les fonctions (pas les wizard), mais l'essentiel pour faire fonctionner la machine est là (en particulier pour reconfigurer l'interface graphique et le réseau).