BISON Critique

Via Ajaxian I got to BISON by Kai Jäger. I’ll ignore the fact that it’s actually quite useless, and also contradicts with an existing GNU utility, and refer to some of the implementation details.

First of all, the writer complains that he was not able to send data with null characters, and also that the data was always converted to UTF-8, which is problematic for binary data. To solve the problem of the null character he uses yEnc, and as for the UTF-8 problem, he simply says it will probably make the BISON data longer (sometimes even longer then the JSON equivalent), which renders the entire effort only useful as a JavaScript exercise.

However, AJAX is certainly capable of sending binary data to the server. For example, Gmail does it when you add an attachment. The attachment is a binary data that can contain null characters. Of course, Gmail might also be using some encoding, but on the other hand, Gmail, being a web app, have no access to the file data until it is passed to the server. I guess Gmail (and everyone else that wants to upload binary data using AJAX) is simply setting the correct header:

xmlHttp.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);

This should solve both problem, as the send data will be encoded in the correct encoding.

BTW, during the encoding discussion he mentions that he chose yEnc since base64 encoding “can sometimes be twice the size of the original unencoded message”. Anyone who knows how base64 encoding works knows that this is almost never true, and as Wikipedia says, “the actual length of MIME-compliant base64-encoded binary data is usually about 137% of the original data length, though for very short messages the overhead can be a lot higher.

I had a look in the JavaScript code itself, and the first thing that came to me was his extensions to the String.prototype object which are done in quite a clumsy way, and can be done a lot nicer (and I think more efficiently) using array trickery.

For example:

String.prototype.repeat = function(times) {
    var repeatedStr = “”
    for (var i = 0; i < times; i++) {
        repeatedStr += this;
    return repeatedStr;

can be written as

String.prototype.repeat = function(times) {
    return new Array(times+1).join(this);

and this

String.prototype.reverse = function() {
    var reversedString = “”
    for (var i = this.length – 1; i >= 0; i–) {
        reversedString += this.charAt(i);
    return reversedString;

can be written as

String.prototype.reverse = function() {
    return this.split(“”).reverse().join(“”)


That’s all for now. I still need to look at the rest of the code to see what it does. I also want to have a look at yEnc – it looks interesting.

5 Responses to “BISON Critique”

  1. Kai Jäger Says:

    Hi and thanks for the feedback. I really appreciate you taking the time to check out BISON. Let me comment on some of the things you mentioned:

    1) As for BISON vs Bison: I wasn’t totally serious about the name BISON and I was also aware that the name was already “in use”. I don’t think this is a real issue though because as you said, BISON is quite useless ;-).
    2) You mention that Gmail uses AJAX to upload attachments. I don’t know where you got that information, but that’s not actually how Gmail does it. The “asynchronous upload trick” actually uses a hidden IFRAME as target for the upload form. AFAIK, that’s also the only “asynchronous” way to upload a file from an HTML page. No chance you could grab the file and pass it through XHR.

    While it’s totally possible to set a Content-Type and even a charset with the XHR object, this does not change the way it treats null-bytes. The null-byte issue arises, because the XHR “send” method treats whatever you pass to it as a null-terminated string.
    As for setting a more appropriate charset: wenn sending something other than XML, the charset will be utf-8 regardless of which charset you specify in the header. Again, that’s understandable because XHR was never intended to be used for sending binary data (Microsofts implementation actually supports it, but not from within JavaScript).
    3.) About base64-encoding: during the tests I performed with base64-encoding, messages were anything from 10 to 100% larger than the original message. The average was around 30%, but since I was trying to get a point across, of course I picked the extreme. Come on, that’s totally legitimate. ;-)
    4.) As for repeat/reverse: sorry, but I usually go for the most obvious solution and not necessarily the shortest, especially with code I’m going to share with others. The real issue here is that I shouldn’t be extending the string prototype in the first place. I don’t really have anything to say in my defense though, except that I will remove this with the next release and put it somewhere inside the BISON constructor.

    I will also post this comment in my blog because I figure that other people might have the same questions/concerns.
    Thanks again for your input and your criticism. Much appreciated.

  2. Kai Jäger Says:

    I lied about the “No chance you could grab the file and pass it through XHR.” thing. Apparently there’s ways that involve ActiveX (=pure evil) or some weird Firefox hack that requires the user to manually change privileges in about:config. These aren’t exactly portable solutions and since the IFRAME hack works nicely, there’s really no reason to use something else.
    These two solutions also suffer from the same charset/null-byte issues that I’m struggling with so encoding needs to be applied here, too.

  3. splintor Says:

    Yes, you are right about uploading a file. When I think about it, Iframe is probably the only way to go.

    Also, I didn’t really check setting the encoding header. I should have before throwing claims.

    I guess that this is because you didn’t mention it in your post, so I thought I’ll teach you something new. Apparently, I failed. Sorry for that. As you said, it might be good to update the post so others will also know you are aware of this.

  4. Kai Jäger Says:

    Yeah, I probably should have mentioned that setting the charset in the header does nothing for plain-text.
    Anyway, thanks for trying to help and all the best!

  5. Binary Serialization Tourguide | Atomic Spin Says:

    […] – C++-specificBISON – Seldom used, doesn’t appear to be a serious project. Critiqued here.Binary XML, Fast Infoset, EXI – focused on serializing XML, so too much baggage for my […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: