Journal Basculer l'informatique en tout-XML?

Posté par .
Tags : aucun
1
19
avr.
2006
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?
  • # Euh..

    Posté par (page perso) . Évalué à 10.

    Qu'en pensez vous ?

    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 (page perso) . Évalué à 3.

      non tu n'as pas compris ...

      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 . Évalué à 10.

        XML est une spec pour ecrire des markup language en ASCII => controle integrité du format facile


        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 . Évalué à 3.

          "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."

          à 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 . Évalué à 5.

            Qu'est-ce que tu appelles une "structure arborescente non-réentrante" ? Parce que le XML, par l'intermédiaire des ref-id, permet d'obtenir non seulement un arbre ordonné et étiqueté, mais aussi un graphe (donc avec des cycles, et tout).
          • [^] # Re: Euh..

            Posté par (page perso) . Évalué à 2.

            d'où RDF...(qui est exprimable en XML notament...)
  • # XML ... XML

    Posté par . Évalué à 7.

    XML est formidable, car il permet d'éviter la programmation d'un format structuré de stockage et d'échange. Deux objectifs : faciliter l'interopérabilité et la manipulation des fichiers de données via un format dont la partie difficile (transformation des données structurées en mémoire en valeur stokables) est déjà implémentée.

    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 . Évalué à 2.

      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.

      Ce que tu décris ressemble furieusement à NetInfo sous OSX :)
      • [^] # Re: XML ... XML

        Posté par (page perso) . Évalué à 1.

        >Ce que tu décris ressemble furieusement à NetInfo sous OSX :)


        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 (page perso) . Évalué à 5.

          Le SGML, dont XML est un sous ensemble est vieux de plus de 20 ans...

          « 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.

          netinfo est une base d'informations , on se fiche mais alors totalement du format utilisé

          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 . Évalué à 10.

    et a quoi ca sert au final ?
    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 (page perso) . Évalué à 2.

      Effectivement, il ne faut pas sombrer dans l'eccès de XML.

      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 (page perso) . Évalué à 4.

        Je suis d'accord pour dire que ce serait souhaitable d'avoir une syntaxe commune.
        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 (page perso) . Évalué à -4.

          gni ? un fichier XML n'est pas éditable dans un éditeur dans un terminal ??
          • [^] # Re: Uniformisation des formats ?

            Posté par . Évalué à 4.

            Le XML n'a jamais été fait pour ça, donc autant l'éviter.
            • [^] # Re: Uniformisation des formats ?

              Posté par . Évalué à 2.

              > Le XML n'a jamais été fait pour ça, donc autant l'éviter.
              Pas d' accord,
              http://www.w3.org/TR/REC-xml/#sec-origin-goals

              The design goals for XML are:

              1.

              XML shall be straightforwardly usable over the Internet.
              2.

              XML shall support a wide variety of applications.
              3.

              XML shall be compatible with SGML.
              4.

              It shall be easy to write programs which process XML documents.
              5.

              The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
              6.

              XML documents should be human-legible and reasonably clear.
              7.

              The XML design should be prepared quickly.
              8.

              The design of XML shall be formal and concise.
              9.

              XML documents shall be easy to create.
              10.

              Terseness in XML markup is of minimal importance.


              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 . Évalué à 2.

                Remarque bien que nul part il est question d'éditer à la main. Quant au mot "reasonably" : il signifie bien faire un format si possible compréhensible.
        • [^] # Re: Uniformisation des formats ?

          Posté par (page perso) . Évalué à 3.

          Il existe déjà et s'appelle YAML !

          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 . Évalué à 4.

            Quitte à troller:
            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 . Évalué à 4.

        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.

        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 (page perso) . Évalué à 10.

    N'oublie surtout pas de proposer un patch pour avoir /proc au format XML, ça va faire fureur sur la mailing-list du noyau.
    • [^] # Re: /proc

      Posté par . Évalué à 10.

      et reimplémenter GNU en GNUX,

      $ <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 (page perso) . É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 . Évalué à 8.

        Ca ca me fait furieusement penser au système de terminal .NET de MS qui manipule des objets à la place des flux textes. J'avais trouvés les exemples assez convaincants : faire une sélection genre SQL sur un sous ensemble des éléments au lieu d'un grep, une sélection d'une colonne au lieu d'un "cut/sed ...". Ca existe pas que chez MS d'ailleurs ce type de shell

        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 (page perso) . Évalué à 4.

          Un genre de truc à la Sqsh ?
          http://www.sqsh.org/
        • [^] # Re: /proc

          Posté par (page perso) . Évalué à 4.

          Mais tu as déjà tout cela dans Perl dés aujourd'hui et dans toute distribution linux (et en plus généralement installé par défaut).

          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 (page perso) . Évalué à 4.

      Franchement ... ça me ferait plaisir, car extraire des infos d'un texte plat tel que /proc/cpuinfo ou /proc/net/tcp c'est plutôt complexe et source d'erreur. Alors qu'un joli XML, il n'y a pas d'erreur possible :-)

      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 . Évalué à 1.

        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 !

        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 (page perso) . Évalué à 3.

          Euh, dans un programme en C je me vois mal appeler "awk .. | cut .." :-P D'une manière générale, je trouve ça bête de sortir l'outil regex pour extraire des infos !

          Haypo
          • [^] # Re: /proc

            Posté par (page perso) . Évalué à 1.

            dans un programme en C je me vois mal appeler "awk .. | cut .."

            Pourquoi ?
            pipe, dup2, fork, exec* et c'est bon...
            • [^] # Re: /proc

              Posté par . Évalué à 5.

              wouhou, welcome back to the 70's.

              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 (page perso) . Évalué à 2.

                wouhou, welcome back to the 70's.

                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 . Évalué à 3.

                  meme en C, on peut utiliser des libs externe.

                  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 (page perso) . Évalué à 4.

    Les fichiers Xogg ne sont pas si inimaginables que ça : le conteneur matroska utilise du ebml qui est paraît-il une sorte de xml binaire. Par contre, c'est évidemment parce qu'il y a plusieurs "flux" de données différents (piste vidéo, pistes son, sous-titres)que cela comporte un intérêt. Pour un fichier dont le format ne devrait pas contenir un arbre de données, cela n'a aucun intérêt.

    > Qu'en pensez-vous ?
    Que si on avait été le premier avril, cela m'aurait fait rigoler.
  • # BEURK!

    Posté par . Évalué à 10.

    Tant qu'à choisir un format universel, pourquoi choisir XML, un format si difficile à employer avec un éditeur ligne à ligne, un format sur lequel il est si difficile d'employer des outils manipulant des expressions régulières, un outil qui rend si difficile la description d'une différence entre deux fichiers, un format aussi verbeux, et, d'une manière générale un format que si peu d'auteurs de logiciels emploient de leur plein gré ?
    • [^] # Re: BEURK!

      Posté par . Évalué à 6.

      Mouarf, en l'occurence tes arguments, c'est surtout que les outils que tu utilise actuellement sont pas du tout adpatés à la manipulation du XML.

      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 (page perso) . Évalué à -1.

      Troll troll troll fud fud fud

      en résumé, Je te dirais : mauvais outils, changer outils.

      un format si difficile à employer avec un éditeur ligne à ligne


      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.

      un format sur lequel il est si difficile d'employer des outils manipulant des expressions régulières


      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...

      un outil qui rend si difficile la description d'une différence entre deux fichiers


      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.


      un format aussi verbeux

      Au moins, il y a plus de chance de comprendre le contenu que des fichiers de conf à la sendmail.

      d'une manière générale un format que si peu d'auteurs de logiciels emploient de leur plein gré


      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 (page perso) . Évalué à 4.

    Quand recodé en Xc(un c xml) le Hurd sera, la world domination du xml tu découvrira.
  • # ça existe déjà... sous MacOS X

    Posté par (page perso) . Évalué à 2.

    Sous MacOS X toutes les applications écrivent leurs paramètres utilisateurs dans des fichiers XML rangés dans le dossier Library/Preferences.

    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 . Évalué à 3.

      Il me semble bien que les fichiers de configuration de .net sont aussi en xml.

      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 . Évalué à 2.

        Et le monde java/j2ee n'est pas en reste ?Qui n'a jamais eu affaire à son projet.xml dans maven ou son struts-config.xml.

        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 . Évalué à 1.

      Je viens d'essayer et c'est rigolo comme tout :)

      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 15 ans !

  • # Roue

    Posté par . Évalué à 6.

    Tu veux tout passer en XML, y compris des données « plates », difficilement structurables en hiérarchie, ou pour lesquelles il n'y a aucun intérêt, que des inconvénients, à les structurer en arbre.

    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 (page perso) . Évalué à 1.

      Au sujet de HTTP, le passer en XML éviterait les vilaines attaques qu'on peut lire régulièrement dans la magazine MISC :-) Requête HTTP-XML non valide (testé via DTD/XML schema) : on droppe :-)

      Haypo
  • # Tant qu'à faire...

    Posté par . Évalué à 5.

    Autant aller jusqu'au bout et ne pas oublier les couches basses du réseau, avec la rfc IP over XML: http://ietfreport.isoc.org/idref/rfc3252/
  • # Espèce de psycopathe :p

    Posté par . Évalué à 5.

    Tout est dans le sujet....

    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 . Évalué à 4.

      Je vais dans ton sens:
      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 (page perso) . Évalué à 2.

    Ça me fait repenser à un post sur thedailywtf :
    http://thedailywtf.com/forums/60879/ShowPost.aspx

    (-->[] parti s'acheter des aspirines)
  • # Ça viole un principe de base...

    Posté par . Évalué à 4.

    If it works, don't fix it !


    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 (page perso) . Évalué à 10.

    XML is like violence. If it doesn't work, use more
  • # Commentaire supprimé

    Posté par . Évalué à 2.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Pour apporter mon grain de sable au moulin

    Posté par (page perso) . Évalué à 1.

    Ya des gens qui commence à utiliser les .yml,
    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
  • # 18 jours de retard?

    Posté par . Évalué à 10.

    Non sérieusement. C'est une blague?

    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 . Évalué à 3.

      Je me donne le badge de la honte pour répondre à mon propre message. Veuillez oublier ma remarque concernant YAML, un petit malin a cru bon d'en faire mention sans m'en parler alors que je tapais mon message.

      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 . Évalué à 4.

      je vois pas grand chose qui utilise du XML
      Je pense que tu devrais sortir de chez toi.
      • [^] # Re: 18 jours de retard?

        Posté par . Évalué à 2.

        Aurais-tu l'extrême obligeance de bien vouloir m'aider à mourir moins bête en me donnant quelques exemples?

        Cordialement,

        G.
        • [^] # Re: 18 jours de retard?

          Posté par . Évalué à 4.

          Ben écoute partout autour de moi au boulot, les applis et les serveurs d'applis utilisent massivement XML comme format de définition de fichier de conf, en parallèle des fichiers de conf clefs/valeurs (.properties java, .ini...).
          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 (page perso) . Évalué à 2.

          Aurais-tu l'extrême obligeance de bien vouloir m'aider à mourir moins bête en me donnant quelques exemples?


          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 (page perso) . Évalué à 2.

      je suis d'accord ... mais globalement, même si un fstab en XML ce ne serait pas la joie, jepense que pour des documents texte structurés (xhtml, docbook, tbook, ...) c'est pas mal ...

      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 . Évalué à 2.

    l'interet de l'xml c surtout l'api , mais on peut faire des format qui utilise la meme api sans la complexite du basilage


    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 . Évalué à 3.


      API compte bien plus que le format , une api standart pour trouver les informations est les modifier c'est le bien. ;-)

      ç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 (page perso) . Évalué à 4.

        > ça se voit que que tu n'as jamais essayé de modifier un doc OOo avec un simple éditeur de texte ...

        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 (page perso) . Évalué à 6.

    Je suis pour le XML dans le réfrigérateur :-) Beaucoup n'ont toujours pas compris ce qu'est le XML : c'est simplement une manière rigoureuse d'écrire des informations (dumoins quand on valide chaque document via une DTD ou XML Schema).

    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 (page perso) . Évalué à 4.

      Il existe aussi le YAML pour les fichiers de configuration. Cela résoud les problèmes de parseur, c'est léger et simple à modifier dans vi.

      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 . Évalué à 3.

    Bon j'arrive "après la guerre", mais ma remarque te servira, au moins :-)

    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 (page perso) . Évalué à 1.

    Pas le /etc/fstab en XML....

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.