W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

From: Chang Shu <cshu01@gmail.com>
Date: Mon, 5 Aug 2013 21:15:47 -0400
Message-ID: <CAMtH1gB0StwDi+k-rFgNgyYH_buGTj+gbBNcF9W1Gj9e=xGOLg@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Simon Pieters <simonp@opera.com>
Hi, Kenneth,

I think the atob implementation is able to enlarge the buffer size
from c++ side if necessary. And during the decoding process, I thought
the algorithm first decodes base64 string into a binary string and
casts/copies it into the desired type based on the input
ArrayBufferView. So it is the user who decides the type of the output
not the encoded string. I think it's the same thing for the current
atob function. The encoded string has no information about what the
type of the output would be. Do you think the above is correct?
There have been some email exchanges about the different approaches of
binary encoding. I was told that the binary encoding part was taken
out of the encoding spec on purpose and the bota/atob approach was
preferred. But people are also talking about bringing it back to the
encoding spec. My bottom line is to have something working so I can
use it in my project. btoa/atob seems a natural enhancement and
low-hanging fruit to me.

> Chang, in your proposal for modifying atob, how does the developer
> know how many characters were written into the outgoing
> ArrayBufferView?
> What happens if the ArrayBufferView argument isn't large enough to
> hold the decoded string?
> During the decoding process, is the type of the ArrayBufferView
> significant? In your example, what would happen if an Int16Array were
> passed instead of an Int32Array?
> The Encoding spec at http://encoding.spec.whatwg.org/ seems to have
> handled issues like these. Perhaps a better route would be to fold
> this functionality into that spec.
> -Ken
Received on Tuesday, 6 August 2013 01:16:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC