Cher journal, j'ai eu une idée que j'ai posé ici : http://forum.jabberfr.org/viewtopic.php?id=419 , mais je ne résiste pas à l'envie de te la présenter.
C'est très simple : aujourd'hui, la majorité des standards ont une syntaxe différente, tant au niveau des protocoles (XMPP, IRC, IMAP, HTTP...) que les fichiers de configurations ( /etc/fstab, ~/.kde/share/config/*, /etc/apache2/httpd.conf). Pourquoi ne pas transcrire tout cela en XML?
J'ai proposé deux petits exemples de ce que pourraient être XIMAP ou XHTTP sur le post sur jabberfr, que je ne peux remettre ici à cause des balises qui sont supprimées...
Sinon, quitte à avoir tout XML, j'avais l'idée d'une sorte de super-serveur qui pourrait tout gérer. Pour l'IMAP, Jabber et SMTP, la cohabitation ne pose pas de problème. Mais HTTP n'a rien à voire avec ça (le client se connecte aux serveurs sans passer par un autre comme c'est le cas avec Jabber et SMTP), d'où mon erreur dans le troisième exemple sur le message du forum.
Niveau local, pourquoi pas transcrire tout les types de fichiers actuels en XML? (et peut-être créer un langage de programmation XML) Voire même de faire un système de fichier basé sur XML?
Bien sûr, pour cette option et même pour toutes se posent le problème du volume des données qui est ainsi considérablement augmenté. Dans ce cas, on peut compresser avec gzip (je ne vois pas un format de compression XML cependant) une partie des fichiers (les gros fichier opendocuments par exemple) voire même les flux réseaux pour ceux qui se connectent dans le métro via gprs payant au ko (excepté ceux avec leur nokia 770 dans les boulangeries wi-fi du coin). Cependant, des fichiers XPNG, Xxvid ou XOGG restent inimaginable du fait de leur objectif qu'est de réduire au maximum la taille du fichier, dans ce cas une exception à la règle peut être faite, au détriment de la simplicité qu'instaure le XML (il est plus facile de lire un opendocument qu'un fichier word non xml dans un éditeur de texte simple n'est-ce pas?).
Pour le système de fichier, là les performances risquent d'être désastreuses, mais qui sait...
Et sinon pour les performances globales du au traitement de toutes ces données XML, je pense que c'est rien face à ce que font déjà les gros projets actuels ;)
Qu'en pensez vous?
Journal Basculer l'informatique en tout-XML?
19
avr.
2006
# Euh..
Posté par Florent Bayle (site web personnel) . Évalué à 10.
Je vois pas bien l'intérêt de remplacer des standards ouverts qui marchent, et qui ont fait leurs preuves de puis pas mal d'années par quelque chose d'autre avec une syntaxe plus lourde.
De même, compresser le XML permet de réduire la bande passante, mais ça va nécessiter une phase de décompression.
On passe donc d'un protocole simple à uun protocole qui nécessite encapsulation XML > compression > décompression > 'parsing' du XML.
Enfin, bref voilà, il va falloir de bons arguments pour me convaincre :-).
[^] # Re: Euh..
Posté par Mouns (site web personnel) . Évalué à 3.
XML est une spec pour ecrire des markup language en ASCII => controle integrité du format facile
au niveau d'un protocole réseau, XML est trop verbeux => compression avec gestion des corrections d'erreur
puis bon, la compression reste claire => crypto à gogo
conclusion ( 3DES sur du LZW d'un truc en XML dont la clé est le SHA du markup ) :
XZDEF NEOF $$******ù%`%$%£ù%é"`233£%((2£éM m(y`ùy YMyù Jm6MMÒÒÒ||?&&(è(§è§è§§&fgdhdfjj"jhjdghjh'hkdkjk"l'ljk"lkjl"kl'kmkmkmtysdxffghgjdgj
n'est ce pas clair dit comme ca ? :)
[^] # Re: Euh..
Posté par a_jr . Évalué à 10.
Quand je code une liste dans un fichier, je ne me sers pas de xml. Je prefere de loin utiliser un separateur (mon favori : le caractere de retour a la ligne pour plus de lisibilite).
Si mes donnees sont corrompues, c'est pas XML qui va me permettre de m'en rendre compte. S'il y a un probleme de separateur, disons que c'est pas tres grave, du moment que le fichier est encore lisible. Si j'avais utilise XML et qu'il y avait un probleme avec un tag, le fichier devient alors illisible au sens XML du terme. Heureusement que le XML est en ASCII me direz-vous. Oui, mais dans ce cas, qu'apporte le XML si c'est pour s'en passer a la moindre erreur ?
S'il y a un probleme de separateur, c'est pas tres grave ai-je mis plus haut. Ca peut etre grave. Mais dans ce cas, c'est pas XML qu'il me faut, mais un controle d'erreur plus robuste tel qu'un calcul de somme de controle. Ici aussi, le XML n'apporte rien, a part un peu de lenteur supplementaire.
Quand il s'agit d'une liste de cles et valeurs, il y a un encodage tres simple qui consiste a mettre sur chaque ligne un format cle=valeur. Le controle d'erreur est ici tres simple : chercher avec grep une ligne ne contenant pas le signe egal (grep -v '=' fichier). Ici aussi, qu'apporterait le XML ?
Bref, l'interet du XML, c'est surtout dans les structures arborescentes et dans les structures extensibles que c'est interessant. Le voir partout serait une erreur je pense.
Le bonjour chez vous,
Yves
[^] # Re: Euh..
Posté par Grumbl . Évalué à 3.
à noter que toute structure arborescente non-réentrante s'exprime dans le plan, par exemple, sous la forme d'un tableau, mais bon... : pourquoi faire simple quand on peut faire compliqué ?
NB: XML ne permet pas d'exprimer les structures ré-entrantes, donc,...
[^] # Re: Euh..
Posté par lasher . Évalué à 5.
[^] # Re: Euh..
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
# XML ... XML
Posté par Anonyme . Évalué à 7.
Parfait parfait, mais comme tu le vois, si tu manipule des données qui ont une utilisation dont les priorités différent de ce qui est précisé si dessus, tu te casse le nez. Ce qui est le cas par exemple, de la vidéo, ou l'objectif n'est pas l'interopérabilité (hum, ca se discute), ou encore, la facilité de lecture/écriture, mais bien d'avoir une taille minimum, quoi qu'il se passe.
Sinon, pour les fichiers de conf en XML, je serais pour (et franchement enthousiaste) le jour ou les dévelloppeurs fournirons :
1) une interface presse bouton pour la configuration pour ceux que ca intéresse et justifier le XML
2) un plugin fuse qui transformera automatiquement mon fichier de conf XML en texte lisible à l'ouverture (identique avec ce que l'on a aujourd'hui, avec les commentaires et tout) et le retransformera en XML tout comme il faut à la sauvegarde.
Voilà ce que j'en pense :)
[^] # Re: XML ... XML
Posté par aurel . Évalué à 2.
Ce que tu décris ressemble furieusement à NetInfo sous OSX :)
[^] # Re: XML ... XML
Posté par oops (site web personnel) . Évalué à 1.
NetInfo date de NeXT en 1989 .....
A l'époque je doute que cela était en XML.
Sous OSX il y a encore plein de fichier ASCII
[^] # Re: XML ... XML
Posté par Ontologia (site web personnel) . Évalué à 5.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: XML ... XML
Posté par - - . Évalué à 1.
les gens confondent avec les fichiers de préférences des applications (les .plist) qui sont écrits en xml (avec un zoli dtd)
apple a toujours défini des langages xml pour ses nouveaux services dans os X
mais n'a jamais forcé un changement sur ce qui marche (tout le pan "unix" de os X utilise toujours les fichiers bsd "plats' tel fstab etc)
quand ils ont remplacé cron et les scripts de lancement des démons par "Launch", ils ont défini toute la configuration en xml. le bon vieux cron n'a pas changé lui.
ils sont pragmatiques globalement.
# pour quoi faire ?
Posté par fabien . Évalué à 10.
enfin je veux dire, a quoi cela sert'il de faire en sorte qu'un client XIMAP utilise le même meta language que le client XHTTP ?
a rien ? d'autant plus que du XML sans savoir que faire des données (sans connaitre le shema) ne sert a rien, le client courier (imap) ne va pas lire du fichier de config fstab-xml, ou autre que sais-je. car c'est un logiciel qui est fait pour UNE tache et pas pour faire du n'importe quoi ?
alors a quoi bon tout uniformiser en utilisant du XML si celà n'apporte rien ?
sauf si c'est pour dire : "woua, le flux http est maintenant codé en xml, c'est la classe, non ?"
je ne peux en conclure qu'une chose : l'exces de XML nuit a la santé mentale :)
[^] # Uniformisation des formats ?
Posté par Émilien Kia (site web personnel) . Évalué à 2.
Mais il y a un point soulevé très juste : c'est la différence des formats de conf actuels, sous Nunux, ya pas trois fichiers de config avec le même format (fstab, xorg ...) ce qui signifie des parseurs différents, des habitudes à prendres pour chaque.
Si ces projets passaient dans un format xml, il serait beaucoup plus simple pour les utilisateurs de les modifier (à la main ou via un programme spécifique) que de le maintenir.
Il existe suffisament de bibliothèques de lecture/manip de xml (avec vérif de schema et tout le toutim) pour ne plus avoir a se palucher les parseurs.
Un jour libre ?
[^] # Re: Uniformisation des formats ?
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 4.
Par contre je préférerai une syntaxe plus simple que xml, ie modifiable avec un éditeur dans un terminal.
[^] # Re: Uniformisation des formats ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à -4.
[^] # Re: Uniformisation des formats ?
Posté par lezardbreton . Évalué à 4.
[^] # Re: Uniformisation des formats ?
Posté par petit_bibi . Évalué à 2.
Pas d' accord,
http://www.w3.org/TR/REC-xml/#sec-origin-goals
A mon sens, le point 6 signifi implicitement: 'Lisible sans trop d' efforts par l' Homme depuis un éditeur de texte brut ( terminal+vi par ex)'
Il me semble que c' est également la raison pour laquelle le binaire brut n' est pas autorisé ainsi que la plupart des caractères de controles...
Personnelement, je trouve que xml est un bon compromis pour tous ces critères.
[^] # Re: Uniformisation des formats ?
Posté par lezardbreton . Évalué à 2.
[^] # Re: Uniformisation des formats ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ca marche très bien et il est très facile de mettre une structure d'arbre la dedans.
Pour ceux qui n'y crois pas et pense que dans deux ans, le YAML est mort, ils se trompent. Tous les paquetages perl du CPAN sont décrit par un fichier YAML qui décrit le contenu du paquet. A comparer avec les fichiers abscons des modules de Tomcat...
On voit vite les limites du XML pour faire des fichiers de configuration. Je suis persuadé qu'on mets moins de temps à faire un fichier YAML de config pour un paquetage Perl que faire le fichier XML du module applicatif Tomcat. D'autant plus que sur mes serveurs, il n'y a aucun outils graphique.
[^] # Re: Uniformisation des formats ?
Posté par golum . Évalué à 4.
les devs de tomcat ont le temps de faire des fichiers de conf avec un langage de structure complexe mais standard car ils ne perdent pas leur temps à essayer de comprendre ce que les autres ont codé.
Déjà dehors =======> [ ]
[^] # Re: Uniformisation des formats ?
Posté par kraman . Évalué à 4.
Mouais..
j'suis pas convaincu.
On aurait exactement le meme probleme avec les adeptes du "attribute" et ceux du "sous elements".
Du coup, des habitudes a prendre pour chaque appli.
C'est sur qu'on uniformise les syntaxes, c'est toujours ca de pris, mais le probleme vient du manque de concertation/entente entre les differents dev.
# /proc
Posté par Pooly (site web personnel) . Évalué à 10.
[^] # Re: /proc
Posté par grafit . Évalué à 10.
$ <command>x-ls</comman>
<?xml version="1.0"?>
<gnux>
<command name="ls" mode="output">
<cookie>ETCHYFDJOSGFCACGKRTDCHH</cookie>
<file date="3245543" rights="rw-r--r--" size="23456">
<name>my-db.dia</name>
</file>
<file date="234564" rights="rw-r--r--" size="903455">
<name>comptes.gnumeric</name>
</file>
<file date="3245543" rights="rw-r--r--" size="23456">
<name>lettre3.sxw</name>
</file>
</command>
</gnux>
$ <command output-mode="good-old-gnu">x-ls</command>
<?xml version="1.0"?>
<gnux>
<parsing-error>
<cookie>DCJDJDDFHVFGHDBHJBGFKBHKVFDGF</cookie>
<message type="error">
<error>command: unknown property</error>
</message>
</parsing-error>
</gnux>
$ Grrrr....
<?xml version="1.0"?>
<gnux>
<command name="Grrrr...." mode="output">
<cookie>SRDTCUJKCGUJGCHTFJDFGCHYFJCFJGFJFGKVJF</cookie>
<message type="error">
<shell>bashx</shell>
<error>command not found</error>
</message>
</command>
</gnux>
$ <command>x-ls</comman> | xsltproc good-old-gnu.xsl
my-db.dia
comptes.gnumeric
lettre3.sxw
:)
[^] # Re: /proc
Posté par chl (site web personnel) . Évalué à 10.
$ <command>x-ls</comman>
Parse error at line 1, column 22, can't close tag <command> :
<command>x-ls</comman>
^
|
---------------------/
[^] # Re: /proc
Posté par Thomas Douillard . Évalué à 8.
Bref, faire apparaître ces données sous forme un poil plus structuré qu'un fichier texte avec des colonnes séparées par défois des espaces, défois des tabulations, et chiant comme la mort à manipuler avec des énormes scripts, perso ça me semble pas une si mauvaise idée, et peut être que ceux qui se moquent en clamant la puissance des outils en ligne de commande du vénérable UNIX vont se prendre des méchantes claques dans la geule dans les futurs trolls MS/Linux si ils font pas gaffe, et si ils regardent pas ce qui ce fait en libre de ce côté ;)
[^] # Re: /proc
Posté par Pooly (site web personnel) . Évalué à 4.
http://www.sqsh.org/
[^] # Re: /proc
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Tu ne fais pas de la ligne de commande pour te prendre un objet illisible en retour. Il y a donc bien de la place entre le shell et le langage de script. Le problème de Microsoft est que son shell est minable et que son langage de script n'est pas beaucoup mieux...
[^] # Re: /proc
Posté par Matthieu Lemerre (site web personnel) . Évalué à 3.
Il vaudrait mieux dire Ruby (avec IRB), ou Lisp (par exemple http://www.scsh.net/)
http://l-lang.org/ - Conception du langage L
[^] # Re: /proc
Posté par lasher . Évalué à 3.
[^] # Re: /proc
Posté par Victor STINNER (site web personnel) . Évalué à 4.
J'ai écris un parseur pour /proc/net/tcp (enfin amélioré un parseur existant) : ben c'est n'importe nawak, faut supposer qu'on ouvre moins de 10000 connexions, et suposer que le texte est bien aligné avec l'entête ce qui est pas tout à fait le cas ... Bref, c'est un peu au pifomètre !
Bon, remarque, à coup de FUSE ça pourrait se faire facilement (/proc_xml :-))
Haypo
[^] # Re: /proc
Posté par wismerhill . Évalué à 1.
Je vois pas le problème, avec un coup de awk on récupère les différents champs sans se prendre la tête. Le format de fichier est fait pour.
Tu peux aussi utiliser cut ou perl suivant ce que tu fais.
[^] # Re: /proc
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Haypo
[^] # Re: /proc
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Pourquoi ?
pipe, dup2, fork, exec* et c'est bon...
[^] # Re: /proc
Posté par kraman . Évalué à 5.
C'est sur que c'est ce qu'on fait de plus propre, de plus sur et de plus portable comme programmation...
Pis le compilateur, on l'emmerde, s'il etait la pour nous aider a programmer, ca se saurait.
En plus d'etre super agreable a utiliser.
[^] # Re: /proc
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
C'est lui qui veut utiliser du C.
Si ça avait été moi, j'aurais plutôt utilisé un vrai langage, comme ruby.
Pis le compilateur, on l'emmerde, s'il etait la pour nous aider a programmer, ca se saurait.
Là j'ai pas compris.
[^] # Re: /proc
Posté par kraman . Évalué à 3.
Là j'ai pas compris.
ce que je veux dire par la, c'est que du awk, ca se compile pas, et ca risque de te peter a la gueule en runtime, alors que si on utilise un compilo, c'est justement pour eviter le plus possible ce genre de choses (dans la mesure de l'acceptable evidemment).
Avec une api, tu peux blinder ton code et gerer tes erreurs proprement, alors que la..
# Xxvid
Posté par 태 (site web personnel) . Évalué à 4.
> Qu'en pensez-vous ?
Que si on avait été le premier avril, cela m'aurait fait rigoler.
# BEURK!
Posté par Grumbl . Évalué à 10.
[^] # Re: BEURK!
Posté par Thomas Douillard . Évalué à 6.
Je trouvais l'idée étrange, un peu naïve, mais franchement, faire un diff/patch avec un fichier XML et des algos adaptés ça me semble pas si une mauvaise idée que ça, par exemple :
<a> <a> prout </a> </b>
<a> <a> bidou </a> </b>
Ca peut s'exprimer simplement en -a/b=>bidou, +a/b=>bidou
Au lieu des numéros de ligne, tu mets un chemin XML (ou XPath, enfin je sais plus trop, je suis pas une star du XML), et la différence entre les deux fichiers.
Les avantages que j'y vois : c'est plus souple qu'un diff/patch, pas forcément linéaire (on doit pouvoir s'y retrouver avec des changement d'ordre entre balise, si éventuellement ca a pas d'importance), peut être avec des plus gros changements, et on doit pouvoir faire des choses un peu plus élaborées si on a le schéma/DTD du fichier XML (une grammaire) au lieu d'un simple algo matching maximal entre deux fichier, qui a ses limitations. En gros, à brule pourpoint comme ça, et environ 5 seconde de réflexion, j'y vois que du bon.
Des commentaires que j'ai vu jusque là, ça ressemblait plutot à "oin, m'enlevez pas mes outils que j'ai si difficilement appris" qu'a une véritable argumentation anti XML.
J'ai pas dit non plus que XML était adapté dans toutes les situations, attention, mais dans le cas des fichiers de conf, je serai plutôt pour. Les regexp par exemple, c'est un bon outil, mais : 1/ c'est pas forcément incompatible avec le XML 2/ Pour certaines utilisations, c'est peut être un palliatif "bricolage" à des technos plus élaborées.
[^] # Re: BEURK!
Posté par Raoul Volfoni (site web personnel) . Évalué à 6.
Ca a déjà été débattu maintes et maintes fois. Jettes donc un oeil à ce thread qui date de 7 ans déjà:
http://lists.debian.org/debian-devel/1999/04/thrd3.html#0129(...)
[^] # Re: BEURK!
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: BEURK!
Posté par Laurent J (site web personnel, Mastodon) . Évalué à -1.
en résumé, Je te dirais : mauvais outils, changer outils.
Oui donc, c'est comme si tu pestais contre ce boulon de douze, en essayant de le dévisser avec une pince à sertir, alors que si tu utilisais une clé de douze, ça irait tout seul... C'est sur l'outil qu'il faut pester, pas le format.
Je ne vois pas pourquoi tu voudrais utiliser des expressions régulières, alors que tu as une API totalement normalisée, qui s'appelle le DOM pour manipuler le document, ou encore XPath, XQuery pour requeter sur son contenu etc...
va voir notre ami google, et demande lui "XML diff".. Il y a plein d'outils/bibliothèque pour connaître des différences entre deux fichiers XML.
Au moins, il y a plus de chance de comprendre le contenu que des fichiers de conf à la sendmail.
Prend pas ton cas pour une généralité :-p
J'ai bien l'impression que bon nombre de ceux qui râlent contre XML, n'y connaisse en fait pas grand chose à XML.
# La consommation aussi devrait passer au XML?
Posté par Vador Dark (site web personnel) . Évalué à 4.
# ça existe déjà... sous MacOS X
Posté par Nicolas Blanco (site web personnel) . Évalué à 2.
Et en double cliquant dessus ça t'ouvre le fichier XML dans un genre d'éditeur semblable à gconf, avec possibilité de modifier des champs.
Ouais, c'est clair que personnellement je trouve ça assez propre. C'est le genre de chose que j'aime bien dans ce systeme. D'un coté ça peut quelques fois etre un avantage qu'une entité décide d'"imposer" certaines règles aux programmeurs.
Dans le monde libre, tous les développeurs font comme ils veulent, bien que quelques fois ils arrivent a se mettrent d'accord sur certains points, mais ça prend du temps...
[^] # Re: ça existe déjà... sous MacOS X
Posté par amadeus029 . Évalué à 3.
Par contre, je ne crois pas qu'il existe un outil generique permettant de gerer ces fichiers.
[^] # Re: ça existe déjà... sous MacOS X
Posté par golum . Évalué à 2.
Un seul truc m'interpelle , après le tout avec des fichier de conf en xml le nouveau paradigme à la mode c'est la convention (Ruby On Rails, Grails, ...)
Unix a donc 20 ans d'avance :-)
===>[]
[^] # Re: ça existe déjà... sous MacOS X
Posté par dinomasque . Évalué à 1.
Par contre toutes les applications n'utilisent pas les Plist (format XML des fichiers de configuration de MacOS X).
Audacity par exemple utilise un bon vieux fichier texte (en même temps c'est du WXchose et pas du Cocoa natif ...)
BeOS le faisait il y a 20 ans !
# Roue
Posté par Sylvain Sauvage . Évalué à 6.
Tu as déjà regardé HTTP ?
Pour la requête, transformer GET http://... HTTP/1.1 en < get url="http://..." version="HTTP/1.1" />, ça change quoi, à part compliquer le parsage ?
Pour la réponse, tu vas transformer
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 128
...
xxxx
en un gros élément racine avec chacun des en-têtes en attribut et le contenu en élément fils (parce qu'il sera en XML et qu'il faudra extraire de façon XML-ienne alors que, pour le moment, il suffit de prendre les « content-length » octets qui suivent les en-têtes)...
Mais bon, imaginons quand même...
Donc, imaginons que tous les transferts se fassent en XML.
Ça me rappelle quelque chose...
Ah oui, tiens, les web services qui, eux, font tout par HTTP. Chouette, passons de HTTP à « XHTTP ».
Et puis on pourrait faire des web services en XML...
Tiens, ça me rappelle encore quelque chose...
Ah oui, les web services en XML, ça ressemble fortement à XML-RPC et SOAP.
Bon. Ben, garde courage, hein. Il n'y a qu'en essayant qu'on peut arriver à quelque chose.
[^] # Re: Roue
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Haypo
# Tant qu'à faire...
Posté par daggett . Évalué à 5.
# Espèce de psycopathe :p
Posté par Guillaume Knispel . Évalué à 5.
Plus sérieusement ça n'a pas grand interet (et c'est même parfois totalement aberrant) dans énormenent de domaine.
Un système de fichier basé sur XML par exemple n'a aucun interet et plein d'inconvénient, idem pour faire une DB par exemple. Techniquement rien n'est vraiment impossible mais les pénalités en terme de perf seront horrible (/ 100? /1000? /10000?), et les gains dans d'autres domaines extrèmenent négligeables ....
De un langage de prog XML serait un vrai cauchemard.
En plus le xml c'est pas beau, trop verbeux et peu lisible par un humain (sauf artifice style indentation).
[^] # Re: Espèce de psycopathe :p
Posté par iTanguy . Évalué à 4.
C'est de l'HERESIE d'informaticien en manque.
C'est completement anti-pragmatique. En general, pour un probleme donné, c'est la solution la plus simple qui est la plus performante.
Avec du XHTTP par exemple ca donne:
a/ des requetes + difficillement generables qu'aujourd'hui
b/ des requetes plus grosses, qu'il faut donc compresser (gzip...), y compris les requetes qui etaient courtes
c/ de l'analyse de requetes plus compliquée: besoin de tout parser (valider le XML, et construire l'arbre en memoire) avant de traiter le contenu [ca necessite temps, ressources CPU, memoire]
bref, ca fait des proxys et des serveurs XHTTP avec un processeur 2 fois plus gros et 4 fois plus de memoire pour la meme performance qu'en HTTP...
Ce que je vois donc c'est une techno (XML) qui n'est pas efficace, donc inadequate, pour tout ce qui est un minimum intensif. Et pour compenser cette inadequation, ben tu colles au dessus une autre techno (compression) pour essayer de compenser le mal ta techno cherie!!! Cette techno inadequate introduit de la complexite en plus, et ca ca a un impact direct sur la performance en general.
Bref, "Keep It Stupid Simple" comme on dit
PS: sur ce qui est moins intensif, ca peut presenter un peu plus d'interet, px sur des fichiers de config... mais faut pas se leurrer, ca compliquera tt de meme les porgrrammes pour la generation et le parsage des fichiers, d'ou certainement un demarrage des applis et du systeme en general plus lent...
# et les bases de données ?
Posté par Pooly (site web personnel) . Évalué à 2.
http://thedailywtf.com/forums/60879/ShowPost.aspx
(-->[] parti s'acheter des aspirines)
# Ça viole un principe de base...
Posté par Serge Julien . Évalué à 4.
Et en outre, bon courage pour faire adopter des nouveaux protocoles qui n'existent pas encore: quand on voit avec quelle inertie se déploie IPv6 (qui existe depuis pas mal d'années déjà), c'est pas gagné...
Ceci dit, pour les fichiers de config, je ne dis pas, faudrait voir...
# N'oubliez pas
Posté par kadreg . Évalué à 10.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Pour apporter mon grain de sable au moulin
Posté par Bactisme (site web personnel) . Évalué à 1.
http://www.yaml.org/
C'est nouveau c'est tout frais, c'est utilisé par exemple dans le framework MVC symfony (http://www.symfony-project.com/ , php5-only)
Ca se veut plus rapide & plus simple à parser, plus simple à comprendre etc...c'est plus better than old xml quoi !
Baptiste
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par golum . Évalué à 5.
Et tu penses vraiment que ca va être human-readable à la 42 èeme balise imbriquée.
Va encore falloir s'exciter sur les ascenseurs horizontaux.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par golum . Évalué à 1.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Bref, le YAML est un truc qui tourne et n'est pas près de s'arréter. Cela m'étonnerais fort que les développeurs Perl remplacent les fichiers YAML par du XML !
Pour ma part, tous mes fichiers de configuration sont en YAML (ou sont un simple systeme clef=valeur). Il est hors de question d'utiliser du XML ou du gconf.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Geraud . Évalué à 1.
http://www.symfony-project.com/trac/wiki/InstallingSyck
La libsyck de why the lucky stiff est une implementation en C. C'est rapide, ca marche tout seul, et ca prend meme pas 5 secondes à trouver sur Google (essaie Yaml +implementation +C)
G.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Bactisme (site web personnel) . Évalué à 0.
# 18 jours de retard?
Posté par Geraud . Évalué à 10.
Bon, d'accord, admettons que ce soit sérieux, ton post a tout de même 3-4 ans de retard. Si, si, souviens toi. La belle époque où tout le monde faisait les louanges du XML, ou l'on entendait partout "XML c'est le futur coco!"...
Aujourd'hui? Mis à part les merveilleux webservices (mais si, les trucs qui on fait éclater tous les buzzword-o-meters de nos managers préférés juste après la période XML-du-sol-au-plafond) je vois pas grand chose qui utilise du XML. Pourquoi? Pour la simple et bonne raison que le XML --attention ça risque de choquer-- c'est une plaie!!! Et qu'on ne vienne pas me parler d'OOo, vous tapez du XML quand vous l'utilisez? ... C'est bien ce que je pensai.
Je vois ici ou là "le XML c'est éditable". FOUTAISES (je reste poli)!!! Ceux qui disent çà sont ceux qui pensent que httpd.conf est un fichier qui utilise toute la puissance du XML parce qu'ils y ont vu <IfModule></IfModule>. Je leur suggère de bien tourner 7 fois leur langue dans la bouche avant de l'ouvrir la prochaine fois. Le XML n'est pas fait pour être édité, le XML c'est 2Mo de charabia imbitable qui vont se faire défoncer par un parser 10 fois plus gros afin de récupérer 5 pauvres lignes de données exploitables.
Admettons. on en arrive au full-XML (systèmes de fichiers, config, protocoles, fichiers, tout... on renomme les protocoles réseau en XTCP/XIP, c'est la fête coco, faut se lacher). TOUT LE MONDE doit devenir un XML guru, c'est une obligation. Pourquoi? Parce que si tu te croutes dans ton XML, tu pêtes tout. Ça vous plairait de plus pouvoir redémarrer votre box parce que la dernière fois que vous avez édité fstab vous avez oublié un "/"? Aaaaaaaaaah, on fait moins les malins maintenant!
Admettons, tous les éditeurs de texte du monde incluent dorénavant des validateurs XML qui vous empêchent de sauvegarder si votre XML n'est pas correct (vous êtes bien sur prêts à envoyer vos patchs pour implémenter cette feature, n'est-ce pas?) pourquoi aller se casser le cul à taper 1000 caractères pour rajouter une ligne dans /etc/fstab? Non, ce qui serait mieux, ca serait de taper le nouveau fs "naturellement" et l'éditeur rajouterait le XML comme un grand en se basant sur une DTD pour l'appli en question. Ouais, ça roske cousin (bien sur, vos patchs sont déjà prêts non?). Et bien alors? Pourquoi se casser le cul a avoir un fichier XML au final, si c'est juste pour taper les infos nécéssaires?
XML est un outil puissant dont l'utilisation devrait être cantonnée aux situations où il est est vraiment indispensable. Pour les autres cas "KISS" devrait être un signal d'alarme universel pour prévenir toute vélléité d'usage du XML.
Un exemple simple qui me vient l'esprit là, tout de suite, maintenant (promis si vous me laissez du temps, je peux en sortir plus), le XML arrange les données sous forme de hiérarchie, d'arbre, de whatever... Pourquoi, ô grand pourquoi, devrait-on utiliser un tel outil pour représenter des données plates? Juste pour le plaisir de faire de la récursion? Mouaip...
Pour les indécrottables convaincus que XML say-le-bien, je vous renvoie aux blogs de certains devs Gnome qui pestaient contre le fait que la majorité des applis se goinffraient de mémoire au lancement juste pour parser du XML. Ce n'est pas parce que la machine que Madame Michu achète aujourd'hui chez [un grossiste en électroménager de votre choix] a 4 fois plus de RAM par défaut qu'il y a 3 ans que les applis doivent être codées de manière porcine.
Pour reprendre une expression utilisée y'a pas si longtemps par sa sainteté Linus himself lors de sa quête d'un nouveau SCMS après les déboires avec BK, le père de melenusme recherchait "the right tool for the right job." XML n'est certainement pas la solution universelle à tous les problèmes. Suivant les cas, les alternatives sont multiples et souvent bien plus utilisables. Je m'étonne que personne n'ai suggéré YAML (par exemple) pour la problématique des fichiers de conf.
mes 0.02Euros
G.
[^] # Re: 18 jours de retard?
Posté par Geraud . Évalué à 3.
méchant!
Note cependant, c'est pas si nouveau que çà : les premières implémentations ont plus de 4 ans, et certains languages tels que Ruby peuvent nativement (c.a.d sans utilisation de module/librairie externe) loader et/ou dumper du YAML.
G.
[^] # Re: 18 jours de retard?
Posté par Pierre Tramonson . Évalué à 4.
Je pense que tu devrais sortir de chez toi.
[^] # Re: 18 jours de retard?
Posté par Geraud . Évalué à 2.
Cordialement,
G.
[^] # Re: 18 jours de retard?
Posté par Pierre Tramonson . Évalué à 4.
Ca va du web.config ASP.NET / app.config C# à la config Hibernate en passant par Ant (build.xml), Struts (struts-config.xml). Sans parler des fichiers de confs des applis spécifiques développées, qui sont soit des .properties, soit des .xml.
Et les personnes qui les utilisent ne s'en plaignent pas.
[^] # Re: 18 jours de retard?
Posté par elloco (site web personnel) . Évalué à 2.
Eh bien moi je vais t'aider à mourir moins bête, avec un exemple plus que concret :
Tu vois le projet safari ? mais non pas le navigateur, celui-là :
http://safari.oreilly.com
Ce projet utilise de l'xml dans tous les sens... et je suis bien placé pour le savoir car je travaille sur ce projet (eh oui, ce sont des belges qui développent ça...)
Je n'ai travaillé que très peu sur la version que tu as accès mais sur la nouvelle version (pas encore accessible) j'ai été énormément impliqué et je peux te dire que de l'XML, j'en vois tous les jours et à toutes les sauces et dans tous les sens. Et ce projet n'est pas petit... crois-moi.
Alors il faudrait sortir de chez toi et découvrir que l'XML est très utilisé. Il ne convient pas pour tout, j'en conçois mais il est très utilisé.
my 0.002 cent
[^] # Re: 18 jours de retard?
Posté par Mildred (site web personnel) . Évalué à 2.
par contre, je préfère quand même pour ces documents les écrire dans un format plus pratique (à la lisp par exemple, ou à la LaTeX ou autre)
le XML c'est quand même pas mal je trouve ... surtout niveau namespaces je trouve. Ceci dit, il existe peut être des formats aussi bien et moins lourds (YAML ?)
# api ou format ?
Posté par Sébastien TeRMiToR . Évalué à 2.
begin{
name="toto"
cache="yes"
::="ici c un block de text dans le flux ce n'est pas un attribut"
bloc{
::="encore du blabla"
}
bloc2{
::="blabla2"
info="c'est un attribut la"
}
::="encore du text"
{
::="'{' seul est un balise anomyne, pourquoi pas?"
}
}
exemple html mis en forme cette facon
html{
title="titre de la page"
meta{
http-equiv="Content-Type"
content="text/html; charset =iso-8859-15"
}}
body{ p{
::="voila un paragraphe"
}}
}
c'est lisible par un humain, faire un editeur qui mes en valeur les differente { } lie suivant le bloc ou l'on ai c'est deja fait.
c'est facile a analyse
on pourrais meme ajouter le nom de la balise a la fin genre }html (pour facilite la lecture par un humain)
mais ce qui compte le plus c'est de pouvoir traiter cela de facon propre
on peut passer de se format au xml et vice versa facilement
gconf utilise aussi du xml, mais l'important c'est l'api de gconf , pas la facon de stocke l'information.
API compte bien plus que le format , une api standart pour trouver les informations est les modifier c'est le bien. ;-)
[^] # Re: api ou format ?
Posté par x0ra . Évalué à 3.
ça se voit que que tu n'as jamais essayé de modifier un doc OOo avec un simple éditeur de texte ...
En passant, puisque tu parles d'API et de format, la grammaire française et l'orthographe existent et sont faites pour être utilisées :/
[^] # Re: api ou format ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Et pourquoi faire ? que ce soit en yaml, xml ou ce que tu veux d'autres, ce genre de document ne sont pas fait pour être éditable "à la main". Il y a beaucoup trop d'informations.
Enfin bon.. Estime toi heureux déjà que ce soit un format textuel. Cependant vu ton caractère hautement masochiste, je te propose d'éditer un fichier .doc dans ton éditeur de texte.. euh pardon.. editeur hexa ;-)
# XML c'est bien
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Si on édite un document XML via un éditeur de texte : oui c'est plus lourd. Par contre, pour un fichier de configuration par exemple, un éditeur dédié serait plus adapté. L'idéal serait un éditeur qui construit des formulaires selon une DTD/XML Schema, chose tout à fait envisageable.
Les documents sont plus gros ? On compresse. Le traitement du fichier XML prend plus de mémoire ? Non je ne pense pas si on utilise SAX. Par contre, oui, il est forcément plus lourd qu'un traitement fait à la main (strcmp, strstr, ...). Je pense qu'il faudrait commencer par écrire une bibliothèque (en C ?) basée par libxml2 qui charge un fichier de configuration XML le plus simplement du monde. bibliothèque générique + éditeur dédié, et voilà, tout le monde est content.
D'ailleurs perso, j'en ai marre de réécrire un parseur chaque fois que je rencontre un nouveau type de fichier (fichier .ini, fichier de config unix, chaque fichier de /proc, etc.). Au moins avec XML, suffit d'écrire un bon parseur une fois pour toute et puis c'est tout !
Avantages du XML : outils existants pour le traiter, document valide ou non (mais pas entre les deux), on connait le charset (UTF-8 par défaut, le pied), inter-opérabilité (à cause du charset entre autres), etc.
Haypo
PS: Dans Wormux, tous les fichiers de config (options du jeu, mode de jeu, graphismes, etc.) sont en XML, et ça plait à tout le monde.
[^] # Re: XML c'est bien
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Pour les grosses structures, les scientifiques ont aussi des solutions qui marchent depuis des années, binaire et multiplateforme : HDF par exemple.
Je ne dis pas que HDF résoud tous les problèmes, simplement qu'il faut arréter de nous mettre du XML partout.
# Correction : *voire* sans -même-
Posté par Olivier Jeannet . Évalué à 3.
Tu as écrit 2 fois "voire même".
Il ne faut pas ajouter "même" comme on l'entend régulièrement, car c'est un pléonasme; on dit tout simplement "voire" (qui signifie à peu près "et même", "et éventuellement").
Mes 2 centimes.
# Ah non pitié...
Posté par Jean-Yves LENHOF (site web personnel) . Évalué à 1.
Vous avez déjà essayé de modifier le fichier server.xml de tomcat dans vi (le mini pas celui avec des couleurs) ben c'est quand meme bien galere....
JY, qui parle un peu pour les admins.....
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.