Protocol buffers de Google

Google vient de sortir un concurrent de XML qui, d'après ses dires, serait "plus succint, plus rapide, et plus simple". Qu'en est-il?

XML étant un standard universel de facto, est-il vraiment besoin de lui créer un concurrent? Avec XPath pour le requêtage (et même LINQ 2 XML côté Microsoft), XSL/T pour la transformation et la conversion en divers formats, XSD pour la structuration, n'a-t-on pas déjà tout ce que l'on souhaite?

Eh bien non. En .NET, nous avons la sérialisation XML et l'outil xsd.exe qui permettent de travailler sur des instances de classes pour manipuler du XML, mais les autres langages n'ont pas cette facilité. Ils doivent parcourir les documents XML avec DOM ou SAX. Du coup c'est compliqué pour eux (comparez les deux lignes qu'il faut pour lire par sérialisation XML en .NET aux vingt lignes qui permettent la même chose en utilisant le DOM).

Il s'agit donc d'une réponse intéressante de Google à la problématique de la manipulation XML en dehors de .NET.

Grosso-modo, comme Google nous l'indique, les protocols buffers sont d'abord définis dans un fichier .proto:

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;
}

Ensuite, on peut directement manipuler le XML via des instances d'objets, comme dans cet exemple:

Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);

On voit tout de suite l'avantage pour des programmeurs Java: plus de DOM, et une manipulation de types du langage, ce qui permet une vérification à la compilation.

En .NET, cela ne va pas nous apporter la simplicité espérée. Car nous pouvons déjà faire la même chose. Pour reprendre l'exemple ci-dessus, il me suffit de déclarer une classe (que je peux aussi me faire générer d'après le XML par xsd.exe):

public class Person
{
    public string name;
    public int id;
    public string email;

    public enum PhoneType
    {
        MOBILE = 0,
        HOME = 1,
        WORK = 2,
    }

    public class PhoneNumber
    {
        public string number;
        public PhoneType type = PhoneType.HOME;
    }

    List<PhoneNumber> phone;
}

Puis d'utiliser le code suivant, strictement équivalent au code précédent Java:

Person person = new Person();
person.name = "John Doe";
person.id = 1234;
person.email = "jdoe@example.com";
XmlSerializer xs = new XmlSerializer(typeof(Person));
xs.Serialize(Console.Out, person);

Nous faisons donc aussi simple et aussi court que les protocol buffers, mais avec l'avantage de ne pas avoir à créer de fichiers .proto ou apprendre un nouveau langage: nos types .NET sont déjà l'équivalent des fichiers .proto.

Google aurait-il simplement réinventé la roue? Oui, mais avec l'avantage de fournir ce superbe outil qu'est la sérialisation XML à des technologies non-.NET comme Java ou C++. Je regrette pour ma part que les .proto ne permettent pas tout simplement de lire du XML.

Reste un autre argument: la rapidité. Google indique que les protocol buffers permettent un traitement plus rapide que le XML, et c'est facile à croire vu que XML est très verbeux. D'ailleurs Microsoft avait utilisé au début un format binaire BAML pour stocker le XAML des applications WPF dans les assemblys.

Au final, que reste-t-il pour nous développeurs .NET? On peut imaginer un outil qui passe des fichiers .proto à des assemblys .NET contenant les mêmes types et inversement. A mon avis il ne faudra pas longtemps avant de voir un tel outil. Du coup nous pouvons continuer à créer et utiliser nos types .NET, ils seront compatibles avec les protocol buffers.