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 alexissoft . Évalué à 2.
[^] # Re: En gros
Posté par alexissoft . Évalué à 2.
[^] # Re: En gros
Posté par Rémi Laurent (site web personnel) . Évalué à 4.
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 Étienne . Évalué à 3.
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 Mes Zigues . Évalué à 7.
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 feth . Évalué à 6.
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 benoar . Évalué à 4.
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 Boa Treize (site web personnel) . Évalué à 4.
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 benoar . Évalué à 2.
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 Mat (site web personnel) . Évalué à 7.
[1] http://fr.wikipedia.org/wiki/Json
[2] http://fr.wikipedia.org/wiki/YAML
[^] # Re: yaml, json, ...
Posté par Rémi Laurent (site web personnel) . Évalué à 3.
[^] # Re: yaml, json, ...
Posté par Mat (site web personnel) . Évalué à 1.
Par contre c'est un projet en ruby, et j'ai l'impression que c'est le seul projet à faire ce genre de choses.
# Pas convaincu
Posté par Guillaum (site web personnel) . Évalué à 2.
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 wilk . Évalué à 2.
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 Amine Mokhtari . Évalué à -1.
---------------------------------------------------------------------------------------------------------------
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 Guillaum (site web personnel) . Évalué à 0.
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 Rémi Laurent (site web personnel) . Évalué à 5.
Ç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 Guillaume Knispel . Évalué à 3.
Heureusement ! :p
[^] # Re: Re : Pas convaincu
Posté par kowalsky . É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 Larry Cow . Évalué à 9.
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 Guillaume Knispel . Évalué à 1.
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 Nicolas Dumoulin (site web personnel) . Évalué à 1.
De pouvoir le convertir en XML :-D
# EBML ?
Posté par karteum59 . Évalué à 3.
http://ebml.sourceforge.net/
# Génial! Y'a plus qu'à tout recommencer!
Posté par Maclag . Évalué à -1.
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 Anonyme . Évalué à 3.
[^] # Re: Génial! Y'a plus qu'à tout recommencer!
Posté par Maclag . Évalué à 2.
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 Anonyme . Évalué à 3.
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 M . Évalué à 3.
[^] # Re: Génial! Y'a plus qu'à tout recommencer!
Posté par Mildred (site web personnel) . Évalué à 4.
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 Tonton Th (Mastodon) . Évalué à 2.
Qu'est ce qu'il ne faut pas lire...
[^] # Re: portnawak...
Posté par Snarky . Évalué à 4.
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 Johan Charpentier (site web personnel) . Évalué à 5.
Hautement lisible : je ne trouve pas qu'un fichier de configuration (par exemple) fait en XML soit hautement lisible
[^] # Re: portnawak...
Posté par Temsa (site web personnel) . Évalué à 3.
[^] # Re: portnawak...
Posté par benoar . Évalué à 1.
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 rhizome . Évalué à 1.
[^] # Re: portnawak...
Posté par yellowiscool . Évalué à 10.
Envoyé depuis mon lapin.
[^] # Re: portnawak...
Posté par Rémi Hérilier . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 3.
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 Ontologia (site web personnel) . Évalué à 3.
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 TImaniac (site web personnel) . Évalué à 2.
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 Frédéric COIFFIER . Évalué à 3.
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 ckyl . Évalué à 4.
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 Larry Cow . Évalué à 7.
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 ckyl . Évalué à 3.
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 Mat (site web personnel) . Évalué à 2.
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 MiniMoi . Évalué à 6.
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 ckyl . Évalué à 4.
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 Jean B . Évalué à -2.
# Compilation
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.