- From: K. Gadd <kg@luminance.org>
- Date: Wed, 7 Aug 2013 12:52:55 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Chang Shu <cshu01@gmail.com>
JSIL currently ships a hand-rolled typed array to/from base64 implementation due not being able to use btoa/atob; if they were improved to support typed arrays as described that would be an improvement for some of my use cases. It'd need to be necessary to detect the presence of the feature at runtime, though. I should also point out that in general string decoding/encoding targetting typed arrays is a really important use case for JSIL (and as I understand things, it is also important for emscripten/embind). Right now moving between JS strings and a fake heap in a typed array is really expensive, and you need to do it any time you leave the domain of your application and talk to HTML5 APIs like canvas, XHR, etc. Base64 isn't the only kind of encode/decode that matters; I'd argue that UTF8 and UTF16 are equally deserving of similar functionality being exposed - if not more deserving. On Wed, Aug 7, 2013 at 3:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu <cshu01@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/ >
Received on Wednesday, 7 August 2013 19:54:02 UTC