[whatwg] API for encoding/decoding ArrayBuffers into text
ian at hixie.ch
Tue Mar 13 16:28:09 PDT 2012
On Tue, 13 Mar 2012, Joshua Bell wrote:
> On Tue, Mar 13, 2012 at 4:10 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> > On Tue, Mar 13, 2012 at 4:08 PM, Kenneth Russell <kbr at google.com>
> > wrote:
> > > Joshua Bell has been working on a string encoding and decoding API
> > > that supports the needed encodings, and which is separable from the
> > > core typed array API:
> > >
> > > http://wiki.whatwg.org/wiki/StringEncoding
> > >
> > > This is the direction I prefer. String encoding and decoding seems
> > > to be a complex enough problem that it should be expressed
> > > separately from the typed array spec itself.
Some quick feedback:
- [OmitConstructor] doesn't seem to be WebIDL
- please don't allow UAs to implement other encodings. You should list
the exact set of supported encodings and the exact labels that should
be recognised as meaning those encodings, and disallow all others.
Otherwise, we'll be in a never-ending game of reverse-engineering each
others' lists of supported encodings and it'll keep growing.
- What's the use case for supporting anything but UTF-8?
- Having a mechanism that lets you encode the string and get a length
separate from the mechanism that lets you encode the string and get the
encoded string seems like it would encourage very inefficient code. Can
we instead have a mechanism that returns both at once? Or is the idea
that for some encodings getting the encoded length is much quicker than
getting the actual string?
- Seems weird that integers and strings would have such different APIs
for doing the same thing. Why can't we handle them equivalently? As in:
len = view.setString(strings[i],
offset + Uint32Array.BYTES_PER_ELEMENT,
offset += Uint32Array.BYTES_PER_ELEMENT + len;
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg