[whatwg] API for encoding/decoding ArrayBuffers into text

[Jonas Sicking]

On Mon, Mar 19, 2012 at 7:00 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> Something that has come up a couple of times with content authors
>> lately has been the desire to convert an ArrayBuffer (or part thereof)
>> into a decoded string. Similarly being able to encode a string into an
>> ArrayBuffer (or part thereof).
>>
>> Something as simple as
>>
>> DOMString decode(ArrayBufferView source, DOMString encoding);
>> ArrayBufferView encode(DOMString source, DOMString encoding,
>> [optional] ArrayBufferView destination);
>
> It saddens me that this allows non-UTF-8 encodings. However, since use
> cases for non-UTF-8 encodings were mentioned in this thread, I suggest
> that the set of supported encodings be an enumerated set of encodings
> stated in a spec and browsers MUST NOT support other encodings. The
> set should probably be the set offered in the encoding popup at
> http://validator.nu/?charset or a subset thereof (containing at least
> UTF-8 of course). (That set was derived by researching the
> intersection of the encodings supported by browsers, Python and the
> JDK.)

Yes, I think we should enumerate the set of encodings supported.
Ideally we'd for simplicity support the same set of enumerated
encodings everywhere in the platform and over time try to shrink that
set.

>> would go a very long way.
>
> Are you sure that it's not necessary to support streaming conversion?
> The suggested API design assumes you always have the entire data
> sequence in a single DOMString or ArrayBufferView.
>
>> The question is where to stick these
>> functions. Internationalization doesn't have a obvious object we can
>> hang functions off of (unlike, for example crypto), and the above
>> names are much too generic to turn into global functions.
>
> If we deem streaming conversion unnecessary, I'd put the methods on
> DOMString and ArrayBufferView. It would be terribly sad to let the
> schedules of various working groups affect the API design.

Streaming is a very good question. I hadn't thought about that.
Especially now that we have chunked ArrayBuffer support in XHR
streaming would seem like a much more interesting request.

/ Jonas