W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: String to ArrayBuffer

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 11 Jan 2012 15:49:54 -0800
Message-ID: <CAD649j64LQXiHqY=m-s9airCZtHVPGkN-gau5-SpUH4GXC4dmg@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
On Wed, Jan 11, 2012 at 3:12 PM, Kenneth Russell <kbr@google.com> wrote:

> The StringEncoding proposal is the best path forward because it
> provides correct behavior in all cases. Adding String conversions
> directly to the typed array spec will introduce dependencies that are
> strongly undesirable, and make it much harder to implement the core
> spec. Hopefully Josh can provide an update on how the StringEncoding
> proposal is going.
>
> -Ken
>

Thanks for the cue, Ken. :)

As background for folks on public-webapps, the StringEncoding proposal
linked to by Charles grew out of similar discussions to this in on the
public_webgl@khronos.org discussion. The most recent thread can be found at
http://www.khronos.org/webgl/public-mailing-list/archives/1111/msg00017.html


If you read that thread it should be clear why the proposal is as "heavy"
as it is (although, being mired in IndexedDB lately, it looks so tiny).
Dealing with text encoding is also never as trivial or easy as it seems.

As far as current status: I haven't done much work on the proposal in the
last month or so, but plan to pick that up again soon, and it should be
shopped around for the appropriate WG (public-webapps or otherwise) for
feedback, gauging implementer interest, etc. Anne's work over on whatwg
around encoding detection and BOM handling in browsers is valuable so I've
been watching that closely, although this is a new API and callers will
have access to the raw bits so we don't have to spec the kitchen sink or
match legacy behavior. There are a few open issues called out in the
proposal, perhaps most notably the default handling of invalid data.


>
> On Wed, Jan 11, 2012 at 3:05 PM, Charles Pritchard <chuck@jumis.com>
> wrote:
> > On 1/11/2012 2:49 PM, James Robinson wrote:
> >
> >
> >
> > On Wed, Jan 11, 2012 at 2:45 PM, Charles Pritchard <chuck@jumis.com>
> wrote:
> >>
> >> Currently, we can asynchronously use BlobBuilder with FileReader to get
> an
> >> array buffer from a string.
> >> We can of course, use code to convert String.fromCharCode into a
> >> Uint8Array, but it's ugly.
> >>
> >> The StringEncoding proposal seems a bit much for most web use:
> >> http://wiki.whatwg.org/wiki/StringEncoding
> >>
> >> All we really ever do is work on DOMString, and that's covered by UTF8.
> >
> >
> > DOMString is not UTF8 or necessarily unicode.  It's a sequence of 16 bit
> > integers and a length.
> >
> >
> >
> > To clarify, I'd want ArrayBuffer(DOMString) to work with unicode and
> throw
> > an error if the DOMString is not valid unicode.
> > This is consistent with other Web Apps APIs.
> >
> > For feature detection, the method should be wrapped in a try-catch block
> > anyway.
> >
> > -Charles
>
Received on Wednesday, 11 January 2012 23:50:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT