Protocol Buffers

Editor's Notes

1. binary not human readable but: platform dependend (Little Endian vs. Big Endian?) + memory efficient fast to parse
2. binary not human readable but: platform dependend (Little Endian vs. Big Endian?) + memory efficient fast to parse
3. Cross platform solutions are text based + human readable (okay, xml...) + platform independend (but: still encoding problems!) + format can evolve (e.g. additional fields in xml ) waste more memory slow to parse
4. From http://www.yegor256.com/2015/11/16/json-vs-xml.html  I believe there are four features XML has that seriously set it apart from JSON or any other simple data format, like YAML for example. XPath. To get data like the year of publication from the document above, I just send an XPath query: /book/published/year/text(). However, there has to be an XPath processor that understands my request and returns 2004. The beauty of this is that XPath 2.0 is a very powerful query engine with its own functions, predicates, axes, etc. You can literally put any logic into your XPath request without writing any traversing logic in Java, for example. You may ask "How many books were published by David West in 2004?" and get an answer, just via XPath. JSON is not even close to this. Attributes and Namespaces. You can attach metadata to your data, just like it's done above with the id attribute. The data stays inside elements, just like the name of the book author, for example, while metadata (data about data) can and should be placed into attributes. This significantly helps in organizing and structuring information. On top of that, both elements and attributes can be marked as belonging to certain namespaces. This is a very useful technique during times when a few applications are working with the same XML document. XML Schema. When you create an XML document in one place, modify it a few times somewhere else, and then transfer it to yet another place, you want to make sure its structure is not broken by any of these actions. One of them may use <year> to store the publication date while another uses <date> with ISO-8601. To avoid that mess in structure, create a supplementary document, which is called XML Schema, and ship it together with the main document. Everyone who wants to work with the main document will first validate its correctness using the schema supplied. This is a sort of integration testing in production. RelaxNG is a similar but simpler mechanism; give it a try if you find XML Schema too complex. XSL. You can make modifications to your XML document without any Java/Ruby/etc. code at all. Just create an XSL transformation document and "apply" it to your original XML. As an output, you will get a new XML. The XSL language (it is purely functional, by the way) is designed for hierarchical data manipulations. It is much more suitable for this task than Java or any other OOP/procedural approach. You can transform an XML document into anything, including plain text andHTML. Some complain about XSL's complexity, but please give it a try. You won't need all of it, while its core functionality is pretty straight-forward. From http://apigee.com/about/blog/technology/why-xml-wont-die-xml-vs-json-your-api JSON is especially good at representing programming-language objects. If you have a JavaScript or Java object, or even a C struct, the structure of the object and all its fields can be easily and quickly converted to JSON, sent over a network, and retrieved on the other end without too much difficulty and (usually) comes out the same on both ends. But not everything in the world is a programming-language object. Sometimes to describe a complex real-world object we have to combine different descriptions and languages from different places, mash them up, and use them to describe even more complex things. The descriptions of these complex things need to be validated, they need to be commented on, they need to be shared and sometimes annotated with additional data that doesn't affect the original structure. When the world gets complicated and open-ended like that, what's needed is not a programming-language-format object, but a open-ended, extensible -- umm -- markup language. That's what we have today with XML.
5. https://opensource.googleblog.com/2008/07/protocol-buffers-googles-data.html
6. https://opensource.googleblog.com/2008/07/protocol-buffers-googles-data.html
7. https://opensource.googleblog.com/2008/07/protocol-buffers-googles-data.html
8. https://opensource.googleblog.com/2008/07/protocol-buffers-googles-data.html
9. https://opensource.googleblog.com/2008/07/protocol-buffers-googles-data.html
10. https://opensource.googleblog.com/2008/07/protocol-buffers-googles-data.html
11. Kodu goster
12. Kodu goster
13. http://www.slideshare.net/SergeyPodolsky/google-protocol-buffers-56085699