Comments on: BISON: Binary JSON http://ajaxian.com/archives/bison-binary-json Cleaning up the web with Ajax Thu, 17 May 2012 07:43:39 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: chris holland http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-250852 chris holland Fri, 25 May 2007 13:57:46 +0000 http://ajaxian.com/?p=2109#comment-250852 typos: s/user/user-agent/ s/well/will typos: s/user/user-agent/ s/well/will

]]> By: chris holland http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-250851 chris holland Fri, 25 May 2007 13:56:31 +0000 http://ajaxian.com/?p=2109#comment-250851 if you're sending JSON from server to client, the HTTP/gzip encoding mechanism should give you good additional compression without having to resort to compressing the data in script-land. HTTP/gzip's been around for ages, all browsers support it, thru proper handshaking: - if a user supports gzip, it well send an Accept-Encoding: gzip http header in every http request to a server. - if a server chooses to gzip the payload it sends back to the client, it MUST also send a Content-Encoding: gzip header. if you’re sending JSON from server to client, the HTTP/gzip encoding mechanism should give you good additional compression without having to resort to compressing the data in script-land. HTTP/gzip’s been around for ages, all browsers support it, thru proper handshaking:

- if a user supports gzip, it well send an Accept-Encoding: gzip http header in every http request to a server.

- if a server chooses to gzip the payload it sends back to the client, it MUST also send a Content-Encoding: gzip header.

]]> By: ajaxianer http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247210 ajaxianer Wed, 14 Feb 2007 17:51:19 +0000 http://ajaxian.com/?p=2109#comment-247210 anyway...DOJO IS slow and browser-unsafe....just my 2 cent anyway…DOJO IS slow and browser-unsafe….just my 2 cent

]]> By: Tom Trenka http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247194 Tom Trenka Wed, 14 Feb 2007 15:01:58 +0000 http://ajaxian.com/?p=2109#comment-247194 Wow! What an ass you are! Don't you think that if I'd implemented gzip with Dojo it would be a part of the toolkit by now? The app I was referring to was an internal IE-only application that I worked on in 2003, long before Dojo was in existence. Don't look down now but your ignorance is open. Wow! What an ass you are! Don’t you think that if I’d implemented gzip with Dojo it would be a part of the toolkit by now? The app I was referring to was an internal IE-only application that I worked on in 2003, long before Dojo was in existence. Don’t look down now but your ignorance is open.

]]> By: handcoder http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247188 handcoder Wed, 14 Feb 2007 13:14:00 +0000 http://ajaxian.com/?p=2109#comment-247188 "(ironically enough, the gzip was actually quite fast; it was the rest of the app that was slow)" maybe coz u use this stupid and terrible slow DOJOTOOLKIT? kick this shit out of your app and it will be fast like hell! “(ironically enough, the gzip was actually quite fast; it was the rest of the app that was slow)”

maybe coz u use this stupid and terrible slow DOJOTOOLKIT? kick this shit out of your app and it will be fast like hell!

]]> By: Tom Trenka http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247154 Tom Trenka Tue, 13 Feb 2007 14:38:49 +0000 http://ajaxian.com/?p=2109#comment-247154 I actually *have* implemented a gzip control on a client (not in pure JS though I do have the start of that laying around somewhere, it's been a while); it was an IE-only intranet application based on passing XML documents from the client to the server and back (not my idea) and because of not-so-careful planning, the size of said documents were pushing the 4MB POST limit (obviously not using multipart).The experience was...um...not the most satisfying. While the size of the packets being sent back and forth were greatly reduced (a 4MB XML file was reduced to around 220k after gzipped and base64 encoded) the fact of the matter is that the browser is really not the best platform to be sending and decoding text of that size. The app in question was *slow* because of this (ironically enough, the gzip was actually quite fast; it was the rest of the app that was slow). I actually *have* implemented a gzip control on a client (not in pure JS though I do have the start of that laying around somewhere, it’s been a while); it was an IE-only intranet application based on passing XML documents from the client to the server and back (not my idea) and because of not-so-careful planning, the size of said documents were pushing the 4MB POST limit (obviously not using multipart).The experience was…um…not the most satisfying. While the size of the packets being sent back and forth were greatly reduced (a 4MB XML file was reduced to around 220k after gzipped and base64 encoded) the fact of the matter is that the browser is really not the best platform to be sending and decoding text of that size. The app in question was *slow* because of this (ironically enough, the gzip was actually quite fast; it was the rest of the app that was slow).

]]> By: Scott Schiller http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247147 Scott Schiller Mon, 12 Feb 2007 23:43:07 +0000 http://ajaxian.com/?p=2109#comment-247147 Kristoffer: I was meaning sending gzipped (or otherwise-compressed) data from the client, from the browser (submitting large amounts of text, for example, comes to mind.) Assuming there would be some bandwidth savings, this might be an interesting area to explore. Kristoffer: I was meaning sending gzipped (or otherwise-compressed) data from the client, from the browser (submitting large amounts of text, for example, comes to mind.) Assuming there would be some bandwidth savings, this might be an interesting area to explore.

]]> By: Robert http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247146 Robert Mon, 12 Feb 2007 22:08:27 +0000 http://ajaxian.com/?p=2109#comment-247146 One thing that author came close to is the idea of obfuscating JSON so it become bit more difficult to reverse engineer. One thing that author came close to is the idea of obfuscating JSON so it become bit more difficult to reverse engineer.

]]> By: Kristoffer http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247141 Kristoffer Mon, 12 Feb 2007 21:11:54 +0000 http://ajaxian.com/?p=2109#comment-247141 I dont think there is a need to implement gzip in javascript. That will be taken care of by the browser before the data reaches the javascript. If the browser supports gzip that is. And since all modern browser do support gzip there is no problem in sending json gziped. I dont think there is a need to implement gzip in javascript. That will be taken care of by the browser before the data reaches the javascript. If the browser supports gzip that is. And since all modern browser do support gzip there is no problem in sending json gziped.

]]> By: Scott Schiller http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247139 Scott Schiller Mon, 12 Feb 2007 19:05:27 +0000 http://ajaxian.com/?p=2109#comment-247139 Peter: File size is a consideration, and presumably processing time (to gzip client-side) as well. Of course, paradoxically, the client-side gzip code could itself be gzipped for fast download to the client. ;) Peter: File size is a consideration, and presumably processing time (to gzip client-side) as well. Of course, paradoxically, the client-side gzip code could itself be gzipped for fast download to the client. ;)

]]> By: Peter Michaux http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247138 Peter Michaux Mon, 12 Feb 2007 18:28:58 +0000 http://ajaxian.com/?p=2109#comment-247138 Theo: That is an interesting idea about implementing gzip in JavaScript. I can't think of any time I would have needed that but it would be an interesting experiment for sure. The savings would need to override the library download. Theo: That is an interesting idea about implementing gzip in JavaScript. I can’t think of any time I would have needed that but it would be an interesting experiment for sure. The savings would need to override the library download.

]]> By: Theo http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247136 Theo Mon, 12 Feb 2007 17:28:56 +0000 http://ajaxian.com/?p=2109#comment-247136 I was going to ask how BISON compares to gzipp'ed JSON, but after reading the other comments I understand that BISON isn't actually producing smaller content anyway. It was probably a fun exercise, but gzipp'ed JSON wins hands down. If one he had implemented gzip in JavaScript instead we could send JSON from the client too, instead of only from the server. I was going to ask how BISON compares to gzipp’ed JSON, but after reading the other comments I understand that BISON isn’t actually producing smaller content anyway.

It was probably a fun exercise, but gzipp’ed JSON wins hands down. If one he had implemented gzip in JavaScript instead we could send JSON from the client too, instead of only from the server.

]]> By: Jamerquai http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247135 Jamerquai Mon, 12 Feb 2007 17:24:33 +0000 http://ajaxian.com/?p=2109#comment-247135 When I encoded the JSON text without whitespace as {info:"Hello, I'm an object",randomNumbers:[9,53,46,12,6,33,59,28],PI:3.14159265,nestedObject:{anotherNestedObject:{yetAnotherNestedObject:{color:"Blue",width:32,height:90}},someArray:[1,4,true,"Hello World",[2,3,4,5],{member:"value"}]}} it is 237 bytes in size. When I fed this JSON to Bison.serialize() it produced a 227 byte string. Why would anyone use this BISON protocol to save only 4% in data transfered? When I encoded the JSON text without whitespace as

{info:”Hello, I’m an object”,randomNumbers:[9,53,46,12,6,33,59,28],PI:3.14159265,nestedObject:{anotherNestedObject:{yetAnotherNestedObject:{color:”Blue”,width:32,height:90}},someArray:[1,4,true,"Hello World",[2,3,4,5],{member:”value”}]}}

it is 237 bytes in size.

When I fed this JSON to Bison.serialize() it produced a 227 byte string.

Why would anyone use this BISON protocol to save only 4% in data transfered?

]]> By: Andrea Giammarchi http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247134 Andrea Giammarchi Mon, 12 Feb 2007 17:18:23 +0000 http://ajaxian.com/?p=2109#comment-247134 oops ... I meant ... "this simple workaround" (... maybe) <code> function BisonSafeArray(arr){ for(var i = 0, j = arr.length, tmp = new Array(j); i < j; i++) tmp[i] = arr[i]; return tmp; }; </code> oops … I meant … “this simple workaround” (… maybe)

function BisonSafeArray(arr){
for(var i = 0, j = arr.length, tmp = new Array(j); i < j; i++)
tmp[i] = arr[i];
return tmp;
};

]]> By: Andrea Giammarchi http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247133 Andrea Giammarchi Mon, 12 Feb 2007 17:16:29 +0000 http://ajaxian.com/?p=2109#comment-247133 It seems a good experiment, but if sent string size is the same of a generic JSONotation, I suppose that serialize/deserialize computation time is not "so interesting" as experiment itself. P.S. I don't understand very well Array limitations (ordered ... why ? ... obj = []; obj[1] = true; obj[0] = true; ... fails your check) ... however, this is a simple workaround. <code>function BSONSafeArray(arr){ for(var i = 0, j = arr.length, tmp = new Array(j); i </code> It seems a good experiment, but if sent string size is the same of a generic JSONotation, I suppose that serialize/deserialize computation time is not “so interesting” as experiment itself.

P.S. I don’t understand very well Array limitations (ordered … why ? … obj = []; obj[1] = true; obj[0] = true; … fails your check) … however, this is a simple workaround.
function BSONSafeArray(arr){
for(var i = 0, j = arr.length, tmp = new Array(j); i

]]> By: Karl G http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247131 Karl G Mon, 12 Feb 2007 16:56:31 +0000 http://ajaxian.com/?p=2109#comment-247131 <blockquote>The XMLHttpRquest object's send method automatically applies utf-8 encoding to anything it sends. This may be fine for text messages, but what I was sending wasn't exactly text. Now utf-8 encoding will encode characters with a numeric represtation that is larger than 128 with anything between two and four bytes. Meaning that when I was thinking I had sent a single byte, I might have actually sent four. Now this problem I could not yet circumvent and while sending and receiving works just fine, the messages are a lot bigger than they have to be. Typically they're about the same size as a JSON message but sometimes they're also bigger.</blockquote> So... binary about the same size as plaintext. Cool hack but doesn't really come off as a net win for me. There's an effort to binary encode XML in the w3c's <a href="http://www.w3.org/XML/EXI/" rel="nofollow">Efficient XML</a> workgroup.

The XMLHttpRquest object’s send method automatically applies utf-8 encoding to anything it sends. This may be fine for text messages, but what I was sending wasn’t exactly text. Now utf-8 encoding will encode characters with a numeric represtation that is larger than 128 with anything between two and four bytes. Meaning that when I was thinking I had sent a single byte, I might have actually sent four. Now this problem I could not yet circumvent and while sending and receiving works just fine, the messages are a lot bigger than they have to be. Typically they’re about the same size as a JSON message but sometimes they’re also bigger.

So… binary about the same size as plaintext. Cool hack but doesn’t really come off as a net win for me.

There’s an effort to binary encode XML in the w3c’s Efficient XML workgroup.

]]> By: Jamerquai http://ajaxian.com/archives/bison-binary-json/comment-page-1#comment-247130 Jamerquai Mon, 12 Feb 2007 16:49:36 +0000 http://ajaxian.com/?p=2109#comment-247130 BISON is the GNU version of Yacc. Hopefully he'll change the name of Binary JSON to "BSON". BISON is the GNU version of Yacc. Hopefully he’ll change the name of Binary JSON to “BSON”.

]]>