3 ms·

Another binary message format? Another language for describing the format instead of XML or JSON? "Why?" is the big question which sits there unanswered.

by cjensen 14y ago

cbsmith 14y ago
I'm with you on this. When Thrift came out, it kind of made sense, because there wasn't really anything quite like it (closest I'd say was Hessian) in terms of the mix of simplicity, performance, etc. When Protocol Buffers came out, it kind of made sense, because Google had worked on it prior to Thrift even existing (indeed, it inspired Thrift). When Avro came out, I was like, WTF!? This is making that mistake yet again!! EDIT: Damn, I forgot to mention MessagePack. ;-)
- mullr 14y ago
  Avro is useful because it also defines a container format which is easily splittable by Hadoop.
  - cbsmith 14y ago
    Yeah, but one could just define a container format. It could have been done with protocol buffers in fact. I know, because I have implemented it.
DHowett 14y ago
XML and JSON violate the following key property (which can be interpreted as a requirement): - Suitability for FPGA implementation
- cjensen 14y ago
  I meant the specification language, not the formatting,
  - randersson 14y ago
    ease of use. It is a much nicer syntax to use when authoring message specs. There are equivalent XML and JSON syntax variants for Blink schemas for those who'd prefer that. Rolf
billwashere 14y ago
I have no idea why they decided but my guess is that * XML and JSON can be slow. * XML parser are big * XML file size is big * JSON lacks proper binary support * Thrift defines a entire transport stack, so if you already have you already have a transport layer, you are adding more bloat * Some people may find protocol buffers and thrift files too hard/tedious * Why not? Sometimes it's easier/more fun to roll out your solution
afuruhed 14y ago
Wire format - performance. Language describing the format - author friendliness compared to more verbose formats. We are going to release specs for an XML schema format and translations to and from the Blink format. The XML format can be used for mappings to and from "external" schemas. Should we do a JSON schema format?
hythloday 14y ago
In games, for example, it's pretty common for bandwidth to be tight enough that a useful optimisation is quantizing floats down to shorts (which is good enough for e.g. quaternion representation of weapon direction). In that environment, the idea of using XML or JSON is ludicrous. (i.e. the Web is not the Internet)

Another binary message format? Another language for describing the format instead of XML or JSON? "Why?" is the big question which sits there unanswered.

by cjensen 14y ago

Another binary message format? Another language for describing the format instead of XML or JSON? "Why?" is the big question which sits there unanswered.

cbsmith 14y ago

I'm with you on this. When Thrift came out, it kind of made sense, because there wasn't really anything quite like it (closest I'd say was Hessian) in terms of the mix of simplicity, performance, etc. When Protocol Buffers came out, it kind of made sense, because Google had worked on it prior to Thrift even existing (indeed, it inspired Thrift). When Avro came out, I was like, WTF!? This is making that mistake yet again!! EDIT: Damn, I forgot to mention MessagePack. ;-)

mullr 14y ago
Avro is useful because it also defines a container format which is easily splittable by Hadoop.
- cbsmith 14y ago
  Yeah, but one could just define a container format. It could have been done with protocol buffers in fact. I know, because I have implemented it.

DHowett 14y ago

XML and JSON violate the following key property (which can be interpreted as a requirement): - Suitability for FPGA implementation

cjensen 14y ago
I meant the specification language, not the formatting,
- randersson 14y ago
  ease of use. It is a much nicer syntax to use when authoring message specs. There are equivalent XML and JSON syntax variants for Blink schemas for those who'd prefer that. Rolf

billwashere 14y ago

I have no idea why they decided but my guess is that * XML and JSON can be slow. * XML parser are big * XML file size is big * JSON lacks proper binary support * Thrift defines a entire transport stack, so if you already have you already have a transport layer, you are adding more bloat * Some people may find protocol buffers and thrift files too hard/tedious * Why not? Sometimes it's easier/more fun to roll out your solution

afuruhed 14y ago

Wire format - performance. Language describing the format - author friendliness compared to more verbose formats. We are going to release specs for an XML schema format and translations to and from the Blink format. The XML format can be used for mappings to and from "external" schemas. Should we do a JSON schema format?

hythloday 14y ago

In games, for example, it's pretty common for bandwidth to be tight enough that a useful optimisation is quantizing floats down to shorts (which is good enough for e.g. quaternion representation of weapon direction). In that environment, the idea of using XML or JSON is ludicrous. (i.e. the Web is not the Internet)