Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, Aug 12, 2013 at 4:50 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Aug 12, 2013 at 12:16 PM, Joshua Bell jsb...@google.com wrote:
To recap history: early iterations of the Encoding API proposal did have
base64 but it was removed with the suggestion to extend atob()/btoa()
instead, and due to the confusion around the encode/decode verbs. If the
APIs were something like StringToBytesConverter::convert() and
BytesToStringConverter::convert() it would make more sense for encoding of
both text (use StringToBytes) and binary data (use BytesToString).
I thought about suggesting something like StringToBytes, but that seems
less obvious for the (probably) more common usage of encoding/decoding a
String, and it's still a bit off (though not *strictly* wrong) for
converting to UTF-16, UTF-32, etc. I tend to think the slightly
unintuitive names of TextEncoder and TextDecoder aren't bad enough that
it's worth renaming them.
For completeness, it's also worth bringing up
https://developer.mozilla.org/en-US/docs/Code_snippets/StringView which
started this round of discussion (over on blink-dev) which is another more
neutral API design for binary/string data interop. I haven't read it
deeply, but it looks like it doesn't handle the streaming case, but does
explicitly tackle base64 without overloading text encoding methods.
While we're re-opening this can of worms, there's been a request to add
a flush() method to the TextEncoder/TextDecoder objects, which would behave
the same as calling encode(null, {stream: false}) / decode(null,
{stream:false}) but make the code more readable. This fails the adding a
new method for something that behaves exactly like something we already
have test. Opinions?
I think you only need to say encode() and decode(), which is less of a
win, especially since creating two ways of doing the same thing means that
people have to learn both ways. Otherwise, they'll see code end with
.encode() and not realize that it's the same as the .finish() they've
been using.
True. (I need to go back through this and other feedback that's trickled in
and see if I'm mis-representing it, and see if there's anything else
lingering.)
On Mon, Aug 12, 2013 at 6:26 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think that base64 encoding fits with the current
TextEncoder/Decoder API. Not because of names, but because base64
encoding is by nature opposite. I.e. the encoded format is in string
form, whereas the decoded format is in binary form.
The names are the only things that are opposite. TextEncoder is just a
streaming String-to-binary-blob conversion API, and TextDecoder is just a
streaming binary-blob-to-String API, and that's precisely what base64
encoding and decoding are. That's the same whether you're converting
String-to-base64 or String-to-UTF-8. The only difference is that the names
we've given to those ideas are reversed here.
Yes.
One thing that might need special attention is that U+FFFD error handling
doesn't make sense for base64; errors should probably always be fatal.
Excellent point.
...
I believe we may experiment with api-base64 and see if there are other
gotchas beyond this and the naming.
--
Glenn Maynard
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Back from a vacation, sorry about the late reply - hopefully still useful.
On Wed, Aug 7, 2013 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu csh...@gmail.com wrote:
If we plan to enhance the Encoding spec, I personally prefer a new pair
of
BinaryDecoder/BinaryEncoder, which will be less confusing than reusing
TextDecoder/TextEncoder.
I disagree with the idea of adding a new method for something that behaves
exactly like something we already have, just to give it a different name.
(It may not be too late to rename those functions, if nobody has
implemented them yet, but I'm not convinced it's much of a problem.)
FWIW, I've landed an experimental (behind a flag) implementation of the API
in Blink/Chromium; changing it is definitely possible for us. I believe Moz
is shipping it web-exposed already in FF?
To recap history: early iterations of the Encoding API proposal did have
base64 but it was removed with the suggestion to extend atob()/btoa()
instead, and due to the confusion around the encode/decode verbs. If the
APIs were something like StringToBytesConverter::convert() and
BytesToStringConverter::convert() it would make more sense for encoding of
both text (use StringToBytes) and binary data (use BytesToString).
While we're re-opening this can of worms, there's been a request to add a
flush() method to the TextEncoder/TextDecoder objects, which would behave
the same as calling encode(null, {stream: false}) / decode(null,
{stream:false}) but make the code more readable. This fails the adding a
new method for something that behaves exactly like something we already
have test. Opinions?
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell jsb...@google.com wrote:
FWIW, I've landed an experimental (behind a flag) implementation of the API
in Blink/Chromium; changing it is definitely possible for us. I believe Moz
is shipping it web-exposed already in FF?
Yes, since Firefox 18 (since Firefox 20 in workers).
To recap history: early iterations of the Encoding API proposal did have
base64 but it was removed with the suggestion to extend atob()/btoa()
instead, and due to the confusion around the encode/decode verbs. If the
APIs were something like StringToBytesConverter::convert() and
BytesToStringConverter::convert() it would make more sense for encoding of
both text (use StringToBytes) and binary data (use BytesToString).
I can't really speak for Gecko, but I suspect we wouldn't like
changing it over half a year after deploying it. Jonas?
While we're re-opening this can of worms, there's been a request to add a
flush() method to the TextEncoder/TextDecoder objects, which would behave
the same as calling encode(null, {stream: false}) / decode(null,
{stream:false}) but make the code more readable. This fails the adding a
new method for something that behaves exactly like something we already
have test. Opinions?
Adding that seems fine.
--
http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, Aug 12, 2013 at 10:27 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell jsb...@google.com wrote:
FWIW, I've landed an experimental (behind a flag) implementation of the API
in Blink/Chromium; changing it is definitely possible for us. I believe Moz
is shipping it web-exposed already in FF?
Yes, since Firefox 18 (since Firefox 20 in workers).
I assume we are talking about TextEncoder/TextDecoder here, and not
new versions of atob and btoa.
If so, yes, we've been shipping that for a while now.
To recap history: early iterations of the Encoding API proposal did have
base64 but it was removed with the suggestion to extend atob()/btoa()
instead, and due to the confusion around the encode/decode verbs. If the
APIs were something like StringToBytesConverter::convert() and
BytesToStringConverter::convert() it would make more sense for encoding of
both text (use StringToBytes) and binary data (use BytesToString).
I can't really speak for Gecko, but I suspect we wouldn't like
changing it over half a year after deploying it. Jonas?
I guess we'd have to do a cost/benefit analysis. What is it that
people want to change about the current API, and why?
Moving to new function names might be doable, by implementing the new
names and adding warnings to the old ones. But we should consider the
confusion it will cause, and how much it will delay deployment.
While we're re-opening this can of worms, there's been a request to add a
flush() method to the TextEncoder/TextDecoder objects, which would behave
the same as calling encode(null, {stream: false}) / decode(null,
{stream:false}) but make the code more readable. This fails the adding a
new method for something that behaves exactly like something we already
have test. Opinions?
Adding that seems fine.
I don't have strong opinions either way.
I don't think that base64 encoding fits with the current
TextEncoder/Decoder API. Not because of names, but because base64
encoding is by nature opposite. I.e. the encoded format is in string
form, whereas the decoded format is in binary form.
I.e. encodings like utf8 and friends encode string data into binary
data. base64 encodes binary data into string data.
/ Jonas
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Because I implemented MS-Office files manipulation in my browser-side XForms implementation, such TextDecoder and TextEncoder are very interesting. Alain Couthures agenceXML http://www.agencexml.com/xsltforms De : Anne van Kesteren Envoyé : mercredi 7 août 2013 06:28 À : Chang Shu Cc : WHATWG On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Wed, Aug 7, 2013 at 11:55 AM, Alain Couthures alain.couthu...@agencexml.com wrote: Because I implemented MS-Office files manipulation in my browser-side XForms implementation, such TextDecoder and TextEncoder are very interesting. To be clear, they are part of http://encoding.spec.whatwg.org/ and implemented in various browsers already. I meant the base64 feature in particular (and maybe API-only true latin1). -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Well, base64 support is also already required in XForms Specifications for encoding/decoding functions to be called by authors whenever they want and also used in custom multipart/related submission. -Alain De : Anne van Kesteren Envoyé : mercredi 7 août 2013 07:02 À : Alain Couthures Cc : Chang Shu; WHATWG On Wed, Aug 7, 2013 at 11:55 AM, Alain Couthures alain.couthu...@agencexml.com wrote: Because I implemented MS-Office files manipulation in my browser-side XForms implementation, such TextDecoder and TextEncoder are very interesting. To be clear, they are part of http://encoding.spec.whatwg.org/ and implemented in various browsers already. I meant the base64 feature in particular (and maybe API-only true latin1). -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On 8/7/2013 5:28 AM, Anne van Kesteren wrote: On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. There are enough places in my code where being able to decode/encode base64 from a typed array is a necessary step that I added helper functions to do this locally, particularly when I am about to shove it through charset conversion as well. Eliminating a copy step would be useful, although I don't think I'm pushing enough data through this functions to make a noticeable performance difference. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth E
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu csh...@gmail.com wrote: If we plan to enhance the Encoding spec, I personally prefer a new pair of BinaryDecoder/BinaryEncoder, which will be less confusing than reusing TextDecoder/TextEncoder. I disagree with the idea of adding a new method for something that behaves exactly like something we already have, just to give it a different name. (It may not be too late to rename those functions, if nobody has implemented them yet, but I'm not convinced it's much of a problem.) -- Glenn Maynard
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Tue, Aug 6, 2013 at 1:41 AM, Kenneth Russell k...@google.com wrote: 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. Yeah, I think my preference would be at this point to expose API-only encodings there. One of those could be base64. Labels for those encodings would simply not be recognized for form and URL. We could even give them labels that suggest that, e.g. api-base64. Another one I've heard requests for is true latin1 which we also use in XMLHttpRequest for various HTTP-related things. -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
If technically no benefit of passing ArrayBufferView as a 2nd parameter to atob, I think returning an ArrayBuffer is a good way to go. Enhancing btoa/atob would be an easy solution while I am open to enhance the Encoding spec. But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. Chang On Tue, Aug 6, 2013 at 8:28 AM, Kornel Lesiński kor...@geekhood.net wrote: On Mon, 05 Aug 2013 21:39:22 +0100, Chang Shu csh...@gmail.com wrote: I see your point now, Simon. Technically both approaches should work. As you said, yours has the limitation that the implementation does not know which view to return unless you provide an enum type of parameter instead of boolean to atob. In that case it'd be better to return ArrayBuffer, so the user can wrap it in any type they want (including DataView). -- regards, Kornel
[whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Hi, all, Based on the discussion in Blink-dev mail group, https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/stringview/blink-dev/ylgiNY_ZSV0/vne3e0aplUUJ, particularly from Adam Bath's suggestion, I drafted a proposal for binary encoding on Typed Arrays by enhancing window.btoa and atob APIs. The text of the proposal is pasted as below. I appreciate your kind review. Chang --- BinaryEncoding Proposed Binary Encoding Web API for Typed Arrays Editors Chang Shu (Samsung Electronics) Abstract This specification enhances the existing window.btoa and window.atob Web APIs to encode directly from Typed Arrays to Base64 strings and vice versa. Use Case Description A webapp sends data from Typed Array to NPAPI plugin and also reads data back. Since the only possible data type supported by NPAPI to send data buffer is text string, an efficient way of converting Typed Array to Base64 string is required. Current Limitations The only existing Web API involving binary data encoding are window.btoa and window.atob. However, they require the raw data being contained in a 'binary' string format while in many cases the raw data is stored in Typed Array. Current Usage and Workarounds Currently, converting Typed Array to 'binary' string can be done in JS functions. But performance is not acceptable for large data buffers. Benefits The new enhancement of btoa and atob converts the raw data in Typed Arrays to text string and from text string to Typed Arrays directly. The performance is the best since all operations are done in native code. Requests for this Feature I would like this feature to be implemented and shipped. Proposed Solutions My Solution The approach is to enhance existing btoa and atob to take Typed Array parameters while keeping backward compatibility. window.btoa Summary Creates a base-64 encoded ASCII string from either a string of binary data or a Typed Array. Syntax var encodedData = window.btoa(dataToEncode); Note that there is no syntax change in window.btoa API. Example var encodedData = window.btoa(hello); //encode a string. Consider the string as 'binary' var arr = new Int32Array(3); arr[0] = 1; arr[1] = 2; arr[2] = 3; var encodedData = window.btoa(arr); //encode integer data into a base-64 string window.atob Summary Decodes a base-64 encoded ASCII string into a string of binary data and a Typed Array if parameter provided. Syntax var decodedArr = new Int32Array(); var decodedData = window.atob(encodedData, [Optinoal] decodedArr); Note that the 2nd parameter is optional which keeps the backward compatibility. Example var arr = new Int32Array(3); arr[0] = 1; arr[1] = 2; arr[2] = 3; var encodedData = window.btoa(arr); //encode integer data into a base-64 string var newarr = new Int32Array(); window.atob(encodedData, newarr); //decode base-64 string back to integer array //newarr[0] should be 1, newarr[1] should be 2 and newarr[2] should be 3.
[whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Hi, all, Based on the discussion in Blink-dev mail group, https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/stringview/blink-dev/ylgiNY_ZSV0/vne3e0aplUUJ, particularly from Adam Bath's suggestion, I drafted a proposal for binary encoding on Typed Arrays by enhancing window.btoa and atob APIs. The text of the proposal is pasted as below. I appreciate your kind review. Chang --- BinaryEncoding Proposed Binary Encoding Web API for Typed Arrays Editors Chang Shu (Samsung Electronics) Abstract This specification enhances the existing window.btoa and window.atob Web APIs to encode directly from Typed Arrays to Base64 strings and vice versa. Use Case Description A webapp sends data from Typed Array to NPAPI plugin and also reads data back. Since the only possible data type supported by NPAPI to send data buffer is text string, an efficient way of converting Typed Array to Base64 string is required. Current Limitations The only existing Web API involving binary data encoding are window.btoa and window.atob. However, they require the raw data being contained in a 'binary' string format while in many cases the raw data is stored in Typed Array. Current Usage and Workarounds Currently, converting Typed Array to 'binary' string can be done in JS functions. But performance is not acceptable for large data buffers. Benefits The new enhancement of btoa and atob converts the raw data in Typed Arrays to text string and from text string to Typed Arrays directly. The performance is the best since all operations are done in native code. Requests for this Feature I would like this feature to be implemented and shipped. Proposed Solutions My Solution The approach is to enhance existing btoa and atob to take Typed Array parameters while keeping backward compatibility. window.btoa Summary Creates a base-64 encoded ASCII string from either a string of binary data or a Typed Array. Syntax var encodedData = window.btoa(dataToEncode); Note that there is no syntax change in window.btoa API. Example var encodedData = window.btoa(hello); //encode a string. Consider the string as 'binary' var arr = new Int32Array(3); arr[0] = 1; arr[1] = 2; arr[2] = 3; var encodedData = window.btoa(arr); //encode integer data into a base-64 string window.atob Summary Decodes a base-64 encoded ASCII string into a string of binary data and a Typed Array if parameter provided. Syntax var decodedArr = new Int32Array(); var decodedData = window.atob(encodedData, [Optinoal] decodedArr); Note that the 2nd parameter is optional which keeps the backward compatibility. Example var arr = new Int32Array(3); arr[0] = 1; arr[1] = 2; arr[2] = 3; var encodedData = window.btoa(arr); //encode integer data into a base-64 string var newarr = new Int32Array(); window.atob(encodedData, newarr); //decode base-64 string back to integer array //newarr[0] should be 1, newarr[1] should be 2 and newarr[2] should be 3.
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, 05 Aug 2013 16:10:50 +0200, Chang Shu csh...@gmail.com wrote:
window.btoa
Summary
Creates a base-64 encoded ASCII string from either a string of
binary data or a Typed Array.
Syntax
var encodedData = window.btoa(dataToEncode);
Note that there is no syntax change in window.btoa API.
Example
var encodedData = window.btoa(hello); //encode a string. Consider
the string as 'binary'
var arr = new Int32Array(3);
arr[0] = 1;
arr[1] = 2;
arr[2] = 3;
var encodedData = window.btoa(arr); //encode integer data into a base-64
string
window.atob
Summary
Decodes a base-64 encoded ASCII string into a string of binary data
and a Typed Array if parameter provided.
Syntax
var decodedArr = new Int32Array();
var decodedData = window.atob(encodedData, [Optinoal] decodedArr);
Note that the 2nd parameter is optional which keeps the backward
compatibility.
Example
var arr = new Int32Array(3);
arr[0] = 1;
arr[1] = 2;
arr[2] = 3;
var encodedData = window.btoa(arr); //encode integer data into a base-64
string
var newarr = new Int32Array();
window.atob(encodedData, newarr); //decode base-64 string back to
integer array
//newarr[0] should be 1, newarr[1] should be 2 and newarr[2] should be 3.
Is there a reason to support an arbitrary typed array for atob rather than
returning a new typed array?
e.g.
var newarr = atob(encodedData, {typedarray:true});
(I'm not sure which view is most appropriate to return.)
--
Simon Pieters
Opera Software
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, Aug 5, 2013 at 12:41 PM, Simon Pieters sim...@opera.com wrote:
var newarr = new Int32Array();
window.atob(encodedData, newarr); //decode base-64 string back to integer
array
//newarr[0] should be 1, newarr[1] should be 2 and newarr[2] should be 3.
Is there a reason to support an arbitrary typed array for atob rather than
returning a new typed array?
e.g.
var newarr = atob(encodedData, {typedarray:true});
(I'm not sure which view is most appropriate to return.)
Decoding into a given typed array means you can reuse the same
(potentially large) buffer multiple times, rather than creating new
ones with every call. Avoiding the GC churn can be significant. It
also means you can decode several strings into the same typed array at
different offsets.
~TJ
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
I see your point now, Simon. Technically both approaches should work.
As you said, yours has the limitation that the implementation does not
know which view to return unless you provide an enum type of parameter
instead of boolean to atob. And mine has the performance issue. How
about we don't return the 'binary' string in case the 2nd parameter is
provided in my case?
Thanks
On Mon, Aug 5, 2013 at 4:22 PM, Simon Pieters sim...@opera.com wrote:
On Mon, Aug 5, 2013 at 3:41 PM, Simon Pieters sim...@opera.com wrote:
Is there a reason to support an arbitrary typed array for atob rather
than
returning a new typed array?
e.g.
var newarr = atob(encodedData, {typedarray:true});
(I'm not sure which view is most appropriate to return.)
On Mon, 05 Aug 2013 21:50:39 +0200, Chang Shu csh...@gmail.com wrote:
Thanks for the comments, Simon. The reason I put the return result as
a second (optional) parameter of atob is for backward compatibility.
User can still call:
var rtn = atob(Base64EncodedData);
and rtn would be a 'binary' string.
If user calls:
var rtn = atob(Base64EncodedData, arrayBufferView);
arrayView would be filled with data and rtn is also a parsed 'binary'
string. I think the native implementation can detect what type of
ArrayBufferView arrayBufferView is.
I think you misunderstood my question.
I understand that
var rtn = atob(Base64EncodedData);
still needs to work for backwards compabitility. But that doesn't explain
why
var rtn = atob(Base64EncodedData, arrayBufferView);
is better than
var newarr = atob(encodedData, {typedarray:true});
Your suggestion to both return a 'binary' string and to fill in the typed
array provided in the second argument seems like it would have bad
performance compared to only filling in or returning a typed array.
--
Simon Pieters
Opera Software
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
That's a very good point, TJ. Thanks.
Chang
On Mon, Aug 5, 2013 at 4:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Aug 5, 2013 at 12:41 PM, Simon Pieters sim...@opera.com wrote:
var newarr = new Int32Array();
window.atob(encodedData, newarr); //decode base-64 string back to integer
array
//newarr[0] should be 1, newarr[1] should be 2 and newarr[2] should be 3.
Is there a reason to support an arbitrary typed array for atob rather than
returning a new typed array?
e.g.
var newarr = atob(encodedData, {typedarray:true});
(I'm not sure which view is most appropriate to return.)
Decoding into a given typed array means you can reuse the same
(potentially large) buffer multiple times, rather than creating new
ones with every call. Avoiding the GC churn can be significant. It
also means you can decode several strings into the same typed array at
different offsets.
~TJ
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, 05 Aug 2013 22:39:22 +0200, Chang Shu csh...@gmail.com wrote: I see your point now, Simon. Technically both approaches should work. As you said, yours has the limitation that the implementation does not know which view to return unless you provide an enum type of parameter instead of boolean to atob. And mine has the performance issue. How about we don't return the 'binary' string in case the 2nd parameter is provided in my case? That works for me. -- Simon Pieters Opera Software
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Mon, Aug 5, 2013 at 2:04 PM, Simon Pieters sim...@opera.com wrote: On Mon, 05 Aug 2013 22:39:22 +0200, Chang Shu csh...@gmail.com wrote: I see your point now, Simon. Technically both approaches should work. As you said, yours has the limitation that the implementation does not know which view to return unless you provide an enum type of parameter instead of boolean to atob. And mine has the performance issue. How about we don't return the 'binary' string in case the 2nd parameter is provided in my case? That works for 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
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
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. Thanks, Chang 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
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On 8/5/13 9:15 PM, Chang Shu wrote: I think the atob implementation is able to enlarge the buffer size from c++ side if necessary. No, it's not. ArrayBuffer sizes are immutable. the algorithm first decodes base64 string into a binary string and casts/copies it into the desired type based on the input ArrayBufferView. Does it cast or copy? That is, does it do the moral equivalent of memcpy, or the moral equivalent of a for loop setting a[i] = b[i]? -Boris
