Google's SPDY To Be Incorporated Into HTTP 2.0
Linked by Thom Holwerda on Wed 25th Jan 2012 22:05 UTC, submitted by twitterfire
Internet & Networking "Google's efforts to improve Internet efficiency through the development of the SPDY (pronounced 'speedy') protocol got a major boost today when the chairman of the HTTP Working Group (HTTPbis), Mark Nottingham, called for it to be included in the HTTP 2.0 standard. SPDY is a protocol that's already used to a certain degree online; formal incorporation into the next-generation standard would improve its chances of being generally adopted."
E-mail Print r 3   12 Comment(s) http://osne.ws/jpi
Permalink for comment 504812
To read all comments associated with this story, please click here.
RE[4]: no binary protocols please
by Alfman on Fri 27th Jan 2012 03:15 UTC in reply to "RE[3]: no binary protocols please"
Alfman
Member since:
2011-01-28

Zifre,

This is the first time I've heard of BSON. I see the mongodb project came up with it.

http://bsonspec.org/#/specification

I read the spec, and to be honest I don't like some of the design choices they made. Some of the datatypes are fixed size, some strings are zero terminated, others have a length prefix, yet another has both a length prefix and is zero terminated (I haven't the foggiest idea why?).



Whereas JSON encapsulates only primary generic datatypes, BSON has started enumerating application specific datatypes like MD5, RegEx, and UUID.

{"Name": "Alfman", "MD5": (string)"md5bytes"}
{"Name": "Alfman", "MD5": (Generic)"md5bytes"}
{"Name": "Alfman", "MD5": (User)"md5bytes"}
{"Name": "Alfman", "MD5": (MD5)"md5bytes"}
{"Name": "Alfman", "MD5": (RegEx)"md5bytes"}
{"Name": "Alfman", "MD5": (UUID)"md5bytes"}

In my opinion this is fundamentally flawed:

Problem 1: Application specific datatypes don't deserve special treatment in a generic transport protocol. Why is SHA not present? What about RSA keys? What about a JPEG datatype?

Problem 2: The *meaning* of a variable is implicitly known by the code which uses it. If it's *expecting* the MD5 field to contain an MD5 hash, there's no need for the transport protocol to tell it that the raw bytes are an MD5 datatype. JSON/XML work fine this way, I can't think of many applications that would benefit from overloading the MD5 field into different datatypes, which is probably always going to be an error.


So in my opinion, BSON is not a good model for a binary HTTP protocol. But I do think a simple binary name/value collection could work nicely.

Edit: it has occurred to me that you didn't actually propose BSON would be suitable for HTTP, but merely used it as an example of a binary container. So maybe my reply is out of context to what you were thinking, but I'll leave my comments anyway.

Edited 2012-01-27 03:27 UTC

Reply Parent Score: 2