[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Typed Arrays & Strings
----- "Joshua Bell" <email@example.com> wrote:
> To leap back in - I'd love to see browser vendors include a JS API
> that allows for string encoding/decoding from Uint8Arrays. At a
> minimum for my scenarios: ASCII, "binary", UTF-8, and Base64 (the
> latter with inverted semantics if the words "encode" and "decode" are
> used). Many libraries fail to properly deal with UTF-16 surrogate
> pairs, so getting it into the browser with a spec and conformance
> tests would be lovely.
> That said, IMHO string encodings don't belong in the TypedArray spec
> or Uint8Array type itself.
I agree here -- I think it would be possible to create a separate spec that depends on Typed Arrays, but provides the specific functionality needed. It sounds like you and Ryan (and others) have a good idea of what would be needed -- would you guys be willing to take a stab at a strawman spec for the functionality? I'd actually urge you to propose it to W3C public-html directly (though don't take that as a "get your dirty strings out of here" request -- you're welcome to bring it up here as well, though even typed arrays are only discussed here out of necessity; would be better if they lived in a general web stack spot :-).
One thing that's not quite clear to me, though... I understand that being able to do string charset conversions would be useful. What I don't understand is the desire to do arbitrary binary string to UTF8-in-UInt8Array conversion and vice versa. Is it possible to just ship raw byte arrays (ArrayBuffer) down across the wire, through XHR/WebSockets instead? Seems much simpler/faster and less error prone than doing charset conversions on binary data.
> One approach would be a Binary/Buffer type with API like Ryan's in
> Node.js that "has-a" (or "is-a") Uint8Array and is what is yielded by
> proposed binary support in XHR, File, and WebSockets. It's certainly a
> clean and easy to understand API.
> But... that would delay being able to lock down any of those other
> specs, though... so perhaps the common currency for binary data should
> really be simply Uint8Array (Vlad, is that what you were showing at
> WebGL camp?), and string<->binary encoding should exist in a separate
> API (e.g. like the CommonJS Encodings proposals)
> (Hopefully I'm being pessimistic about the speed at which a
> Binary/Buffer type can be settled on.)
> Vlad: does there need to be any further discussion on this list, or do
> you have all the requirements? Should continued discussion stay here,
> or be redirected to... bugzilla?
Well, see above -- I think that neither Ken nor I really understand the requirements, but that's probably ok, since this is a fairly independent chunk from typed arrays themselves. However, I'd definitely like to understand the potential use cases through a new proposed spec for the charset conversions.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: