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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
22 matches
Mail list logo
