Commentaires sur : XML versus Protocol Buffer

Par : Albéric

Albéric — Thu, 20 May 2010 11:53:37 +0000

Je pense que le xml a l’avantage d’être plus clair que protocol buffer pour la simple raison que l’on est vite perdu à la fermeture de beaucoup de crochets alors que la fermeture d’une balise est explicite. Protocol buffer est par contre bien plus ordinateur. pourquoi ne pas compiler le XML comme si c’était du protocol buffer? La syntaxe ne me parrait pas rédibitoire.

Par : elazzouzi

elazzouzi — Fri, 17 Jul 2009 18:37:10 +0000

Oui j’ai regardé le principe de Thrift, c’est une piste intéressante, je vais faire le test. Merci beaucoup pour vos réponses.

Par : Damien B

Damien B — Wed, 15 Jul 2009 21:11:04 +0000

@elazzouzi

Ha, j’aurais dû me douter que « méta-modèle » était une référence directe à UML. Dans un cas comme ça, nous avons utiliser Thrift sur un projet. Pour la communication serveur / serveur (ou en roundtrip par le client avec valeur opaque) on utilisait le message au format binaire. Pour la communication serveur / client, l’encodeur Thrift sait aussi encoder en JSON (sur les mêmes structures de données). Etant donné que ça doit être consommé par du Javascript, je ne suis pas sûr que ça vaille la peine de le garder en binaire.

Par : elazzouzi

elazzouzi — Tue, 14 Jul 2009 22:18:44 +0000

Merci pour votre réponse. Et le but pour le cas précis que j’ai annoncé précédement c’est la sérialisation structurée des données tout en ayant un gain de performance par rapport à XML. par exemple pour représenter un diagramme de classe UML, ca sera simplement un message de la forme
message class{
required string calssName = 1;
required string calssId = 2;

enum AttributeType {
STRING = 0;
INTEGER = 1;
FLOAT = 2;
…..
}

message Attribute{
required string arrtibuteName = 1;
required AttributeType arrtibuteType = 2;
optional string defaultValue = 3 ;
…..
}

repeated Attribute attributes= 3;
……
}
Et apres bénificier du gain en performance pour faire transiter des messages de ce type sur le réseau vue que l’application s’exécute sur le web (c’est une application de modélisation en ligne et collaborative).

Par : Christian

Christian — Tue, 14 Jul 2009 21:32:10 +0000

Merci pour ces précisions Damien

Par : Damien B

Damien B — Tue, 14 Jul 2009 16:22:07 +0000

@elazzouzi
EMF permet de gérer des modèles et des outils associés (éditeurs de documents basés sur ces modèles sous forme de plugin Eclipse par exemple), ainsi que de participer à l’écosystème Eclipse (par exemple GEF travaille sur des modèles définis dans EMF) ou tout simplement en déploiement OSGi.
ProtocolBuffer de l’autre côté (ou Thrift d’ailleurs) n’a aucune prétention dans une forme de communication autre que de machine à machine. Il n’y a pas d’outillage associé, pas plus que de moyen d’exprimer de contraintes en-dehors du typage simple des données (pas de restriction définissable sur les plages de valeur, etc).

Par : Dirty Harry

Dirty Harry — Tue, 14 Jul 2009 15:54:45 +0000

@Christian JSON : pas forcement tributaire du Javascript… avec n’importe quel langage on peut imaginer le parser
comme Yaml finalement

Par : elazzouzi

elazzouzi — Tue, 14 Jul 2009 14:10:31 +0000

Bonjour,
Je suis en train de faire une étude de faisabilité sur l’utilisation de Protocol Buffers pour manipuler des méta-modèles en mode web (Modélisation sur une infrastructure web), Eclipse Modeling Framework permet de générer des classes java permettant de manipuler un méta-modèle, est ce que P.B peut être une solution qui remplace EMF? quel sont les pertes dans ce cas?

Par : bobiciel

bobiciel — Sun, 28 Sep 2008 22:51:50 +0000

je ne vois vraiment pas ce qu’apporte cette syntaxe par rapport à la forme xml suivante :

Sous forme d’attributs, le seul caractère supplémentaire par rapport à protocol-buffer est le / final !
Sous cette forme, on conserve la possibilité d’utiliser tous les outils xml pour valider et transformer. Et l’encodage binaire est tout aussi réalisable et performante qu’avec protocol-buffer
(http://code.google.com/apis/protocolbuffers/docs/encoding.html)

Attention à comparer ce qui est comparable. Concernant les performances annoncées, il s’agit du parsing de la forme binaire, donc incomparable à de l’xml ascii (ni du protocol-buffer ascii d’ailleurs !).

Bob

Par : Christian

Christian — Sat, 27 Sep 2008 17:07:49 +0000

@ Alain : bien sûr dans le publishing la question n’est pas la même.
Faudrait vraiment avoir une idée derrière la tête pour le préférer à du XML…