Journal Google offre un format de donnée sous licence Apache

Posté par (page perso) .
Tags : aucun
1
10
juil.
2008
Bonjour,

Voilà que Google donne sous licence Apache 2.0 un de ses formats d'échanges données nommé « Protocol Buffers ».

C'est un format dit « alternatif » aux actuels XML, qui, selon eux, n'est pas vraiment adapté aux échanges en masses. Son avantage principale face aux XML est sa compacité (de l'ordre de 10), mais elle garde tout de même l'intérêt du XML qui est d'avoir des fichiers humainement lisible et modifiable.

Ce format se base sur un fichier .proto, qui définit la structure des données des fichiers (type de donnée / répétabilité / valeur par défaut / ect...). Ce fichier doit être compilé avec un petit outils à eux, pour fournir des fichier .h .cc ou .java selon le langage.
Voici un exemple du fichier proto :
message Person {
required string name = 1;
optional string email = 3;
}


Ensuite, il suffit d'écrire les fichiers sous ce format qui seront parser avec les types reconnu automatiquement :
person {
name: "John Doe"
email: "jdoe@example.com"
}


Et on accède au contenu parsé à l'aide d'un classe spécifiquement crée à l'aide de getteur et setteur :
Person person;
cout << "name: " << person.name() << endl;
if (person.has_email()) {
cout << "e-mail: " << person.email() << endl;
}

ou :
Person person;
person.set_name("Bob");
person.set_email("bob@example.com");



Je voudrais savoir ce que vous pensez de ce format en particulier, car je ne vois pas vraiment de gros soucis face à l'XML. Au contraire même, avec leurs outils, c'est presque plus facile à mettre en place.


Page du protocole avec exemples & sources :
http://code.google.com/p/protobuf/

Source de l'information :
http://www.silicon.fr/fr/news/2008/07/09/google_livre_un_for(...)
  • # En gros

    Posté par . Évalué à 2.

    C'est comme Thrift de chez Facebook, à la sauce Google, si j'ai bien compris.
    • [^] # Re: En gros

      Posté par . Évalué à 2.

      Ouuppsss... Thrift c'est un machin pour faire des RPC, et Message buffers un format de données. Mais Google utilise Message buffers pour faire des RPC. Donc c'est pas pareil, c'est juste différent.
    • [^] # Re: En gros

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

      Moi ça me fait penser aux principes utilisés par ASN1, sauf que la syntaxe semble un peu plus abordable.

      Il y a aussi la possibilité de créer des types imbriqués l'un dans l'autre, mais j'ai pas vu de bout de code montrant comment les accéder. Des gens avec les yeux mieux ouverts ?
      • [^] # Re: En gros

        Posté par . Évalué à 3.

        Par exemple sur http://code.google.com/apis/protocolbuffers/docs/cpptutorial(...)

        package tutorial;

        message Person {
          required string name = 1;
          required int32 id = 2;
          optional string email = 3;

          enum PhoneType {
            MOBILE = 0;
            HOME = 1;
            WORK = 2;
          }

          message PhoneNumber {
            required string number = 1;
            optional PhoneType type = 2 [default = HOME];
          }

          repeated PhoneNumber phone = 4;
        }

        message AddressBook {
          repeated Person person = 1;
        }
      • [^] # Re: En gros

        Posté par . Évalué à 7.

        Ils réinventent la roue, ANS.1 leur auraient rendu le même service avec moins d'efforts.

        ASN.1 est plus vieux, donc plus complet, et permet des chose très compliquées. ASN.1 est largement utilisé, il existe même des outils pour manipuler les strucutres ASN.1 dans des programmes.

        ASN.1 contient 2 parties, une partie définition de donnée et une partie encodage.

        La partie définition de données ressemble à du Ada, le langage est très puissant.
        La partie encodage définit les règles de passage de la structure de données à une suite de bits (sérialisation et codage des nombres par exemple). Le résultat est compact, voir très compact.

        Les recommandations ASN.1 ( http://www.itu.int/rec/T-REC-X.680-X.693/e ) définissent des règles d'encodage des définitions de ASN.1 en XML.
        Il est possible de passer de XML vers un des encodage ASN.1.

        La différence essentielle entre ASN.1 et XML est que l'encodage XML est verbeux et peut transporter la définition de données : en XML on est capable de recevoir un document basée une structure de données qui n'est pas préalablement connue et de dire si ce document est syntaxiquement juste ce qui est impossible avec ASN.1.

        Ainsi, ASN.1 sera préféré pour l'échange de données entre machines, en particulier pour les protocoles de communication, quand la structure de données est prévue pour être stable dans le temps alors que XML sera utilisé pour le support des échanges entre humains ou des applications dont la structure de données est peu stable et qui nécessite d'être mise à jour et contrôlée régulièrement sans la connaître préalablement.
  • # bon, ça a l'air bien mieux que JSON

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

    Merci pour un journal informatif et sourcé, d'abord.

    Ensuite, moi aussi j'adore les get-setteurs, ils parlent un mixed franglish tout à fait fashion :)

    Pour finir, ce sont les implémentations qui sont en Apache, parce qu'un format de données n'a pas de licence en soi. Un brevet, pourquoi pas, mais pas de licence.
    • [^] # Re: bon, ça a l'air bien mieux que JSON

      Posté par . Évalué à 4.

      un format de données n'a pas de licence en soi
      Va dire ça à Adobe et les "conditions d'utilisation" du format Flash, ou alors à MS et son "Open promise" ....
      • [^] # Re: bon, ça a l'air bien mieux que JSON

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

        C'est la documentation du format qui est sous license. Si tu arrives à respecter le format sans la documentation, ils n'ont rien à dire, à moins d'avoir un brevet sur le format.

        Le truc typique ensuite, c'est bien sûr de n'autoriser à utiliser la trademark que les personnes qui ont correctement implémenté le format, c'est à dire entre autres payé la doc (et probablement les tests de certification).
        • [^] # Re: bon, ça a l'air bien mieux que JSON

          Posté par . Évalué à 2.

          (désolé de répondre si tard, mais le sujet est intéressant, et j'avais laissé passer ce commentaire)

          Qu'il y ait une licence sur la documentation elle-même (genre comme la GFDL), d'accord, je comprend tout à fait que c'est leur travail, et qu'ils y mettent la licence qu'ils veulent : cela concerne donc la distribution/recopie de la doc elle-même.

          Par contre, obliger quelqu'un à faire quelque chose (genre respecter à 100% leur doc) ou même l'en empêcher (ne pas coder de lecteur !) s'il se base sur cette documentation, je trouve ça complètement aberrant. Le travail n'est pas le leur, comment peuvent-ils dirent "vous n'avez pas le droit de faire ci ou ça" ?! Quant à vouloir dire (j'anticipe un peu) que c'est un travail dérivé si on a lu la licence, je trouverai ça très tiré par les cheuveux.
  • # yaml, json, ...

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

    Je n'ai pas détaillé énormément, mais ca ressemble pas mal au Json [1], ou même au Yaml[2].

    [1] http://fr.wikipedia.org/wiki/Json
    [2] http://fr.wikipedia.org/wiki/YAML
    • [^] # Re: yaml, json, ...

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

      En YAML/JSON il y a de quoi créer des "types" personnalisés et valider que les données fournies correspondent bien à la structure attendue ? une sorte de DTD en fait.
  • # Pas convaincu

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

    Tout d'abord il faut voir que le format XML se compresse plutot bien, mais c'est vrai que le PF doit fournir un gain de taille interessant.

    Maintenant ce que je n'aime pas c'est qu'il n'existe des implementation que pour Java, c(++), Python. Personellement je n'utilise que c et python, mais c'est dommage de faire un format qui n'est pas bien supporté. De plus on parle d'un format d'echange, le type principal d'echange au quel je peux penser qui aurait besoin d'un format leger c'est le web "ajax". Ou est la version javascript de ce truc ? Fasse au 12000 format leger pour le web (Json par example), qu'apporte il de plus.

    Je n'aime pas non plus que cela genere du code, je deteste les choses qui genere du code (pour des raisons de praticité, de coherance, de portabilite et de securité).

    C'est quoi ce = 1 ?

    <<< The " = 1", " = 2" markers on each element identify the unique "tag" that field uses in the binary encoding. Tag numbers 1-15 require one less byte to encode than higher numbers, so as an optimization you can decide to use those tags for the commonly used or repeated elements, leaving tags 16 and higher for less-commonly used optional elements. Each element in a repeated field requires re-encoding the tag number, so repeated fields are particularly good candidates for this optimization. >>>

    Si on en est a ce stade, autant faire son propre fichier binaire, la on est certain de maitriser l'optimisation. Mais, il y a quelque chose que je ne comprend pas. En fait si il y a cette notion de tag avec un numero, cela veut dire que le fichier est transformé en quelque chose de binaire quelque part dans le processus ? Donc c'est plus lisible par tout le monde et en plus c'est un nouveau format binaire ? Ou alors je n'ai rien pigé. A ce compte la je prefere utiliser les interface de serialisation de mes langages.

    Ce que j'aime, un langage de definition du format qui est elegant et simple. Pour le XML je n'ai jamais rien trouvé de la sorte. Ecrire une DTD ou un XML Schema est toujours autant long lourd et moche.

    Bref, hormis le schema de definition leger qui est sympa (au final autant que si je declarais ma classe dans mon langage favoris) et le format d'echange qui semble leger (autant que ma serialisation dans mon langage favoris), que m'apporte ce format ?
    • [^] # Re: Pas convaincuj

      Posté par . Évalué à 2.

      J'ai compris comme toi, l'intérêt de perf et de taille c'est quand le format binaire est utilisé
      http://code.google.com/apis/protocolbuffers/docs/encoding.ht(...)
      Ce n'est du coup plus du tout lisible...
      Ce que je comprend c'est en gros qu'on a là un format binaire pour échanger des données entre c++, java et python.
      Bof aussi donc...
    • [^] # Re : Pas convaincu

      Posté par . Évalué à -1.

      voilà leur réponse (http://code.google.com/apis/protocolbuffers/docs/overview.ht(...)
      ---------------------------------------------------------------------------------------------------------------
      Why not just use XML?

      Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

      * are simpler
      * are 3 to 10 times smaller
      * are 20 to 100 times faster
      * are less ambiguous
      * generate data access classes that are easier to use programmatically
      -----------------------------------------------------------------------------------------------------------

      Apparemment c'est juste un problème de performance. Avec leurs formats ça va plus vite. Forcement si c'est un binaire (plus besoin d'interpréteur).

      Je n'y crois pas tellement. S’ils veulent des échanges rapides en XML, ils n'ont qu'à optimiser une librairie existante ; non!!!!!!
      • [^] # Re: Re : Pas convaincu

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

        * are simpler
        Ok, j'avoue, comme je le disais, j'aime bien leur format de definition.
        * 3 to 10 times smaller
        Autant que mon format de serialization utilisé avec Python.
        Au passage, 10 times smaller je n'y crois pas. XML implique une augmentation de poid importante je l'accorde, mais hormis dans le cas ou les noms de balise sont tres long et le contenu est tres cours, cela n'est pas de l'ordre de 10.
        * Faster
        Ok. Autant que mon format de serialization utilisé avec Python ?
        * Less ambiguous
        Je n'ai jamais trouvé le XML ambigus, juste les DTD illisibles.
        * generate data access classes that are easier to use programmatically
        Je n'aime pas la generation automatique de code et j'avoue ne jamais avoir traité de XML avec autre chose que Python, mais j'ai presque la meme chose avec Python. (en fait en 10 minutes de tests avec ElementTree (la lib de traitement de XML avec python) et un peu d'introspection, je fais la meme chose ;)

        >>> Je n'y crois pas tellement. S’ils veulent des échanges rapides en XML, ils n'ont qu'à optimiser une librairie existante ; non!!!!!!

        Tu ne feras jamais aller un parseur XML plus vite qu'un parseur binaire, puisque pour un parseur XML tu est forcé de traiter caracteres par caracteres, pour un parseur de fichier binaire n'as pas ce probleme la.

        >>> Ce que je comprend c'est en gros qu'on a là un format binaire pour échanger des données entre c++, java et python.

        Cela peut etre son aventage, mais le nombre de langage supporté sera toujours limitant, bien que je ne m'inquiete pas, chaque communautée va ecrire son adaptateur dans la semaine. D'autant que cela n'est pas trop en accord avec un fonctionnement sur un langage non objet.

        Les criteres etant donc:

        - Communication entre plusieurs langages, on a deja le XML pour ca.
        - Bindage automatique sur des objects, moui, cela marche aussi avec le XML
        - Vitesse. Le jour ou je commencerais a m'inquieter de la vitesse de traitement sur un truc qui est fortement dependant d'une IO, c'est que tous le reste de mon code sera parfait (j'ai hate)
        - Poid. Argument presque valable, bien que je ne pense pas que cela soit de l'ordre de 10. Mais si le poid pose vraiment probleme, il existe deja des choses comme JSON qui permettent tout cela deja, non ?
        - Syntaxe de l'equivalent a la DTD simple. Ca c'est bien ! Cela implique juste un format limité au final ?
        • [^] # Re: Re : Pas convaincu

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

          - Vitesse. Le jour ou je commencerais a m'inquieter de la vitesse de traitement sur un truc qui est fortement dependant d'une IO, c'est que tous le reste de mon code sera parfait (j'ai hate)

          Ça doit être pour ça qu'on croise si peu de XML et encore autant d'ASN1 dans le domaine des télécoms ;)
          • [^] # Re: Re : Pas convaincu

            Posté par . Évalué à 3.

            Ça doit être pour ça qu'on croise si peu de XML et encore autant d'ASN1 dans le domaine des télécoms ;)

            Heureusement ! :p
      • [^] # Re: Re : Pas convaincu

        Posté par . Évalué à 10.



        Je n'y crois pas tellement. S’ils veulent des échanges rapides en XML, ils n'ont qu'à optimiser une librairie existante ; non!!!!!!



        Ce n'est pas en améliorant la bougie que l'on a inventé l'ampoule !
    • [^] # Re: Pas convaincu

      Posté par . Évalué à 9.

      le type principal d'echange au quel je peux penser qui aurait besoin d'un format leger c'est le web "ajax".

      Alors tu manques vraiment d'imagination. Beaucoup. Des échanges de données structurées et typées, tu en as partout. Pas seulement sur le web. Pas seulement dans des applications réseau.

      La sérialisation, ça sert vraiment partout. Et une sérialisation moins bourrine qu'en XML, c'est un vrai bol d'air frais. Parce que le XML a toutes les sauces, on finirait par en oublier à quoi ça sert. Pondre du XML quand tu n'as pas la moindre idée de l'application qui va relire tes données, ça se justifie. Pondre du XML pour échanger des données entre deux bases de code que tu maîtrises, c'est un peu comme laver les carreaux à coups de marteau.

      Maintenant ce que je n'aime pas c'est qu'il n'existe des implementation que pour Java, c(++), Python. Personellement je n'utilise que c et python, mais c'est dommage de faire un format qui n'est pas bien supporté.

      [...]

      A ce compte la je prefere utiliser les interface de serialisation de mes langages.

      Donc en gros, tu râles parce que c'est un format qui n'est pas (encore) implémenté par des langages que tu n'utilises pas, mais que tant qu'à faire tu préfères quand même utiliser un format propre à UN langage unique? Damn'it...
    • [^] # Re: Pas convaincu

      Posté par . Évalué à 1.

      Je n'aime pas non plus que cela genere du code, je deteste les choses qui genere du code (pour des raisons de praticité, de coherance, de portabilite et de securité).

      Tu devrais programmer en langage machine alors.

      Concernant le principe c'est la même idée de base que l'ASN.1

      PB _est_ un langage de définition de format qui est simple.
    • [^] # Re: Pas convaincu

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

      que m'apporte ce format ?

      De pouvoir le convertir en XML :-D
  • # EBML ?

    Posté par . Évalué à 3.

    Ce ne serait pas un peu équivalent au EBML (utilisé dans le format MKV) ?
    http://ebml.sourceforge.net/
  • # Génial! Y'a plus qu'à tout recommencer!

    Posté par . Évalué à -1.

    Alors, on met jabber à la poubelle et on refait un nouveau protocole?

    Sérieusement, est-ce que ça veut dire que google voudrait lâcher xmpp et se retaper le boulot avec leur nouveau format?
    • [^] # Re: Génial! Y'a plus qu'à tout recommencer!

      Posté par . Évalué à 3.

      Je sais pas ou est ce que tu as vu qu'il était question pour google. de ne plus utiliser du tout de xml ...
      • [^] # Re: Génial! Y'a plus qu'à tout recommencer!

        Posté par . Évalué à 2.

        Ben Je ne sais pas non plus où t'as vu que je pensais que Google allait ne plus du tout utiliser de xml (?!?)

        Ma question portait sur XMPP!

        GTalk utilise XMPP, est c'est très bien, ça permet l'intéropérabilité, tout ça.
        Par contre, s'ils pensent que ce serait mieux pour leurs futures applis embarquées (Androïd) d'avoir un autre format pour la communication, ils aligneront forcément les applis bureau!

        Et là ils mettent déjà en avant la "légèreté" du truc.

        Et sinon, s'ils proposent ce format, c'est bien pour s'en servir, non?
        • [^] # Re: Génial! Y'a plus qu'à tout recommencer!

          Posté par . Évalué à 3.

          Et sinon, s'ils proposent ce format, c'est bien pour s'en servir, non?

          Oui mais s'en servir quand ca a du sens, pas s'en servir à tout prix pour dire qu'ils l'utilisent..
    • [^] # Re: Génial! Y'a plus qu'à tout recommencer!

      Posté par . Évalué à 3.

      Ben c'est ce qu'il ont fait dans android depuis longtemps...
    • [^] # Re: Génial! Y'a plus qu'à tout recommencer!

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

      Il me semble que xmpp utilise les namespaces XML ... Cela permet entre autre de rajouter des extensions. Et je ne pense pas que le projet dont on parle ici permet cela.

      Ceci dit, n'existe-t-il pas une version sérialisée binaire de XMl standardisée ? Si c'est le cas, je la verrais bien utilisée pour XMPP.

      XML c'est bien, mais perso, je trouve deux grands inconvénients:
      - on prétend que c'est humainement lisible, mais en fait, pas vraiment. On a pas vraiment la possibilité de faire une indentation (les espaces comptent même si ils sont ignorés par après) et sa verbosité le rend finalement très peu pratique dans un éditeur de texte.
      - il requiert un parsing, et il me semble que pour faire des bon parseurs, ce n'est pas si simple que ça (sauf si on se limite a un sous-ensemble de XML bien sûr)

      Donc il est entre un format texte bien lisible et un format binaire, n'ayant ni les avantages de l'un, ni les avantages de l'autre.

      http://c2.com/cgi/wiki?XmlSucks
  • # portnawak...

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

    garde tout de même l'intérêt du XML qui est d'avoir des fichiers humainement lisible

    Qu'est ce qu'il ne faut pas lire...

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: portnawak...

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

      Développe...

      Quand je dis humainement lisible, je parle pas de madame michu non plus.... C'est juste pour dire que c'est pas binaire.
      • [^] # Re: portnawak...

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

        Lisible oui...
        Hautement lisible : je ne trouve pas qu'un fichier de configuration (par exemple) fait en XML soit hautement lisible
      • [^] # Re: portnawak...

        Posté par . Évalué à 1.

        J'aodre le coup du "binaire" pas lisible.
        En informatique, tout est "binaire".
        Le truc, c'est que comme l'ASCII (puis l'unicode)(qui décrivent un format binaire, quand même) c'est répandu partout et que donc aujourd'hui c'est sûr qu'on peut le lire depuis n'importe quel appli. Mais il faut rappeler qu'un format, c'est à la base toujours quelque chose de binaire. Il y a juste une question de popularité, disponibilité, etc.
        Faut-il rappeler qu'au début de l'informatique, il existait d'autre format que de l'ASCII pour écrire du texte ?

        Tout ça me rappelle un peu le taffe où je suis en ce moment, où on se passe des dumps binaires .... écrits en ASCII (des fichiers remplis de F3A5FB780..... en ASCII ..... même pas du base64, hein !)
        • [^] # Re: portnawak...

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

          Tiens, bizarre que tu ai été moinssé. C'est pourtant le post le plus intéressant de ce fil.
    • [^] # Re: portnawak...

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

      Mince, j'écris mes pages xhtml (du xml donc) à la main. Je ne serais donc qu'un bot ?

      Envoyé depuis mon lapin.

    • [^] # Re: portnawak...

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

      Qu'est ce qu'il ne faut pas lire...

      les formats Microsoft Office Open XML avec <insérez votre éditeur de texte préféré> ?
  • # Personnelement, je ne trouve pas le xml lisible

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

    Depuis quelques temps, je bosse sur des projets J2E avec plein de xml dans tous les sens (surtout les jsp tout en xml), parce qu'on adore programmer en xml dans ce monde là, et ça me confirme une impression que j'avais depuis longtemps :
    Le xml c'est pas très joli, et même bien indenté, c'est pas très lisible pour l'humain.

    Pour les échanges entre machine, c'est vraiment un standard génial et très bien pensé, mais en terme de facilité de lecture, le truc de google, ou le YAML sont bien plus agréable, bien plus intuitifs.

    Après, déterminer si la proposition de google est mieux/moins bien que YAML, je ne saurais pas me prononcer sur un tel troll. Notons que la page d'accueil du site d'yaml est elle même en yaml et parfaitement lisible : http://www.yaml.org/

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Personnelement, je ne trouve pas le xml lisible

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

      J'ai mal formalisé, en xml, il y a les DTD, Xml Shema, XSL, XQuery, Xpath, etc...
      En Yaml and al. pas grand chose.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Personnelement, je ne trouve pas le xml lisible

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

      L'intérêt du XML c'est qu'il est facilement manipulable par toute une floppée d'IHM qui t'évites justement de devoir te le coltiner à la main :)
      Le 2ème intérêt, c'est qu'en l'absence d'IHM, t'as toujours un bête éditeur texte.
      • [^] # Re: Personnelement, je ne trouve pas le xml lisible

        Posté par . Évalué à 3.

        Ah ? Une IHM ? Libre ??? Il existerait un éditeur XML libre ??? Et utilisable ????
        La dernière fois que j'ai regardé, je suis reparti avec mon éditeur de texte...
        • [^] # Re: Personnelement, je ne trouve pas le xml lisible

          Posté par . Évalué à 4.

          Eclipse marche vraiment pas mal. Que ce soit pour l'édition de XSD ou de fichier plus classiques.

          Le problème c'est que beaucoup de gens semblent utiliser XML pour stocker trois valeurs qui serait tout aussi bien en CSV.

          L'interet d'XML c'est les outils qu'il y a autour et qu'ils sont facile à modifier. Pas de parser a réinventer, XPath, XQuery, XSLT, Xinclude, pas mal d'API pour la serialization automatique etc. C'est pas parfait mais ca fait gagner un temps fou de développement et pour faire évoluer les fichiers. Pour des fichiers de conf c'est plus douteux, mais au moins ca permet d'avoir une complétion "universelle".

          Par contre si c'est pour faire communiquer deux processus proprio avec des contraintes de performance alors ca vaut peut être le coût de réinventer la roue. Et c'est la que se place "Protocol Buffers".

          Récemment j'ai fait des stats sur les résultats des test unitaires et fonctionnels des 10 000 derniers builds d'un projet. Chaque résultat d'un build est stocké dans un ou plusieurs fichier XML, et le schema a évolué 3/4 fois. Apres 10 minutes d'XSLT j'avais tout reformaté en un gros fichier CSV, uploadé ca sur un cluster Hadoop DFS et commencé a sortir des stats avec Pig.

          Je n'ai réinventé aucun outil. Du logiciel qui pond le fichier, à celui qui le transforme. Et une expression XPath reste toujours plus parlante qu'une série de grep | cut | awk | cut | sort | uniq. Et franchement, y'a plus intéressant à faire que de la manipulation de fichier dans l'informatique !
          • [^] # Re: Personnelement, je ne trouve pas le xml lisible

            Posté par . Évalué à 7.

            Eclipse marche vraiment pas mal.

            Et dire qu'on se plaignait de le lourdeur d'Emacs...

            Blague à part, Eclipse est un bon IDE, et effectivement le mec qui fait du J2EE a probablement déjà un Eclipse de lancé et peut s'en servir pour éditer son XML. Soit.

            Mais les autres? Le mec qui a trois paramètres à changer sur un serveur sans tête à l'autre bout du monde (joignable en SSH uniquement, et encore, faut rebondir sur un premier serveur avant d'atteindre le bon)?

            Cela dit, je suis d'accord, la tendance actuelle à mettre du XML partout, même là où un méchant format "key=value\n" suffit, c'est un peu usant.

            Pour le XPath qui est plus parlant, ça dépend vraiment des gens. C'est sans doute vrai dès que tu manipules du XML, oui. Mais sur l'équivalent "à plat" de bien des fichiers XML, ta chaîne de pipes reste très largement lisible, plus selon moi que bien des horreurs en X{Query,Path}.
            • [^] # Re: Personnelement, je ne trouve pas le xml lisible

              Posté par . Évalué à 3.

              > Et dire qu'on se plaignait de le lourdeur d'Emacs...

              Effectivement. Encore plus que la lourdeur c'est surtout qu'eclipse est pas du tout conçu pour fonctionner avec des fichiers seuls (pas de projet).

              Un bon éditeur XML ca serait pas du luxe, quand je vois le nombre de mecs qui éditent du XML avec vim et se tapent 25 essais d'exécution alors qu'un éditeur validant permet de régler le truc en 5 secondes.

              > Pour le XPath qui est plus parlant, ça dépend vraiment des gens.

              Tu peux faire des trucs bien moches avec toutes les technos.

              Reste que six mois après tu comprends encore assez facilement ce que l'expression suivante fait.

              my $nodeset = $job_xml->find('//*/child/child[statu=\'REGRESSION\']/className/text()');
              foreach my $node ($nodeset->get_nodelist) {
              print "\t", "NEW ", XML::XPath::XMLParser::as_string($node), "\n";
              }


              Si tu peux formater en CSV; alors CSV ou XML sont plus ou moins équivalents. Cela dit il est plus facile de rajouter des attributs ou des éléments à un fichier XML en gardant tes outils qu'en CSV. De même tu peux représenter beaucoup plus de concept. Bref tout est question de dosage en fonction des objectifs et contraintes que tu as.
            • [^] # Re: Personnelement, je ne trouve pas le xml lisible

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

              Cela dit, je suis d'accord, la tendance actuelle à mettre du XML partout, même là où un méchant format "key=value\n" suffit, c'est un peu usant.

              Je plussoie avec ferveur.

              Je travaille avec Java de nombreuses années, et j'ai voulu par curiosité essayer le framework .NET ( par l'intermédiaire de Mono, faut pas déconner qd même :P ) pour un petit projet perso, histoire de voir à quoi ça ressemblait.
              Pour faire qque chose de pas trop crade, je me dis bêtement : "tiens si je faisais un petit fichier de propriétés histoire d'avoir une config lisible plutôt qu'une floppée de paramètres en ligne de commande".
              Alors je me mets à chercher un équivalent de la classe PropertyFile en java (qui comme son nom l'indique gère un fichier de propriétés de type clé=valeur ainsi que les commentaires).

              Que nenni ! Ce n'est pas dans l'api de base ! /0\
              "On est modernes en .NET mon bon monsieur, l'avenir c'est le XML, oubliez vos obsolètes fichiers de propriétés".

              Bref, j'ai moi même implémenté la classe PropertyFile :P
  • # Pour avoir travaillé 1 an à Google

    Posté par . Évalué à 6.

    Donc, comme le dit le titre de ce commentaire, pour avoir travaillé 1 an à Google, je peux dire que ce format est extrêmement pratique. Ca fait donc un an que j'utilise les protocol buffers tous les jours, et c'est definitivement quelque chose d'agreable.

    Ok, il y a quelques differences. En premier lieu le fait que la librarie publiee est plus avancee que celle utilisee actuellement en interne, ce qui est plutot pas mal, mais l'actuelle est deja plus que bien.
    C'est un avantage incroyable de pouvoir communiquer entre serveurs si facilement juste en passant des protocol buffers. C'est aussi tres pratique de les stocker, et d'avoir une interoperabilite entre langage, plus un parsing sans y penser du tout. En XML il faut toujours ecrire le parseur, ici rien a faire !

    En plus les performances sont reellement excellentes, si vous en dutez, allez sur google.com et faites une recherche. Il n'y a pas d'autre moen d'echanger des donnees par RPC a Google, et je pense que vous pouvez reconnaitre que ca marche plutot bien.

    En gros, je pense que ca devrait remplacer XML autant que possible, et que Google rend un enorme service au libre et a la communaute du logiciel en general.

    Et pour ceux qui parlent d'autres langages de markup recents, la plupart sont loins des protocol buffers en performance, et il ne faut pas oublier que les protocol buffers sont en usage depuis 5 ans au moins, en interne...
    • [^] # Re: Pour avoir travaillé 1 an à Google

      Posté par . Évalué à 4.

      > En XML il faut toujours ecrire le parseur, ici rien a faire !

      Autant je suis d'accord avec toi pour le reste. Autant cette affirmation est fausse. Tu as au moins une dizaine d'implémentations qui te font le mapping automatique XML vers langage Objet (idem pour les DB). Pour les perfs c'est autre chose.

      Les deux solutions semblent complémentaires. XML beaucoup plus généraliste et puissant. Protocol Buffer offre beaucoup moins de fonctionalités qu'XML puisqu'il cible mieux ses utilisateurs potentiels. Il est donc plus concis et rapide en déportant les traitements possibles en XML de la lib vers le code utilisateur.

      C'est une bonne chose d'avoir une nouvelle alternative puisque la plupart des gens utilisent du XML pour tuer une mouche. Et donc la valeur ajouté par forcement significative.
    • [^] # Re: Pour avoir travaillé 1 an à Google

      Posté par . Évalué à -2.

      Et est-ce que tu vas au coiffeur ?
  • # Compilation

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

    Quelqu'un est arrivé à compiler leurs magnifiques outils ?

    Envoyé depuis mon lapin.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.