On Jan 10, 2014, at 10:26 AM, Anne van Kesteren wrote:

> On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that
>> StringView [1] over ArrayBuffers  be added to ES.
>> 
>> [1]
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView
> 
> Where is this from?

Don't know, I'm just creating visibility of the ES bug/feature request.
> 
> Google and Mozilla have implemented the API from
> http://encoding.spec.whatwg.org/ as a means to get strings out of
> bytes (and bytes out of strings). It's not clear we need anything
> else.

Same base point applies to that proposal.  If anybody wants this capability to be considered as a standard ES capability, it needs to have a champion within TC39.  I note that (as would be expected) the whatwg encoding spec. is expressed in WebIDL terms (DOMStrings, etc.) and it isn't yet clear to me how well it integrates with ES, ES standard library conventions,  or non-browser hosts.  Perhaps it's fine to leave this as a web platform API , but support for character set encoding/decoding  is a general purpose capabilities and it might be reasonable to have a solution that isn't tied to a specific environment.

Allen

On Jan 10, 2014, at 10:26 AM, Anne van Kesteren wrote:

> Where is this from?

Don't know, I'm just creating visibility of the ES bug/feature request.

> Google and Mozilla have implemented the API from
> http://encoding.spec.whatwg.org/ as a means to get strings out of
> bytes (and bytes out of strings). It's not clear we need anything
> else.

Same base point applies to that proposal.  If anybody wants this capability to be considered as a standard ES capability, it needs to have a champion within TC39.  I note that (as would be expected) the whatwg encoding spec. is expressed in WebIDL terms (DOMStrings, etc.) and it isn't yet clear to me how well it integrates with ES, ES standard library conventions,  or non-browser hosts.  Perhaps it's fine to leave this as a web platform API , but support for character set encoding/decoding  is a general purpose capabilities and it might be reasonable to have a solution that isn't tied to a specific environment.