Any further input on Kenneth's suggestions?
Re: ArrayBufferView vs. DataView - I'm tempted to make the switch to just
DataView. As discussed below, data parsing/serialization operations will
tend to be associated with DataViews. As Glenn has mentioned elsewhere
recently, it is possible to
On Wed, Apr 4, 2012 at 11:09 AM, Joshua Bell jsb...@chromium.org wrote:
Any further input on Kenneth's suggestions?
I largely disagree with those suggestions, because I don't believe they
align with the natural, intuitive usage of the API.
Re: ArrayBufferView vs. DataView - I'm tempted to
On Sat, Mar 31, 2012 at 6:13 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Mar 28, 2012 at 1:44 AM, Jonas Sicking jo...@sicking.cc wrote:
Scanning over the buffer twice will cause a lot more memory IO and
will definitely be slower.
That's what cache is for. But: benchmarks...
We can
On Sun, Apr 1, 2012 at 5:28 PM, Jonas Sicking jo...@sicking.cc wrote:
I'm saying that if an API is better in every way then it doesn't seem
like an interesting discussion how much better, we should clearly go
with that API.
It's not a different API, it's an *additional* API. (Assuming that
On Wed, Mar 28, 2012 at 1:44 AM, Jonas Sicking jo...@sicking.cc wrote:
Scanning over the buffer twice will cause a lot more memory IO and
will definitely be slower.
That's what cache is for. But: benchmarks...
We can argue weather it's meaningfully slower or harder. But it seems
like we
On Tue, Mar 27, 2012 at 4:45 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 27, 2012 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
The memchr is purely overhead, I.e. we are comparing memchr+decoding
to decoding. So I don't see what's backing up the probably the
fastest thing claim.
On Tue, Mar 27, 2012 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
The memchr is purely overhead, I.e. we are comparing memchr+decoding
to decoding. So I don't see what's backing up the probably the
fastest thing claim.
If you don't do it as an initial pass, then you have to embed null
On Mon, Mar 26, 2012 at 10:28 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Mar 26, 2012 at 6:11 PM, Kenneth Russell k...@google.com wrote:
On Mon, Mar 26, 2012 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell jsb...@chromium.org wrote:
* We
On Tue, Mar 27, 2012 at 7:12 PM, Kenneth Russell k...@google.com wrote:
- I think it should reference DataView directly rather than
ArrayBufferView. The typed array spec was specifically designed with
two use cases in mind: in-memory assembly of data to be sent to the
graphics card or audio
On Tue, Mar 27, 2012 at 6:44 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 27, 2012 at 7:12 PM, Kenneth Russell k...@google.com wrote:
- I think it should reference DataView directly rather than
ArrayBufferView. The typed array spec was specifically designed with
two use cases in
On 3/25/12 7:45 AM, Geoffrey Sneddon wrote:
On 21/03/12 04:31, Mark Callow wrote:
On 17/03/2012 08:19, Boris Zbarsky wrote:
I think that trying to get web developers to do this right is a lost
cause, esp. because none of them (to a good approximation) have any
big-endian systems to test on.
On Sat, Mar 24, 2012 at 6:52 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren ann...@opera.com
wrote:
Another way would be to have a second optional argument that indicates
whether more bytes are coming (defaults to false), but I'm not sure of
the
On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell jsb...@chromium.org
wrote:
Bikeshed: The |continues| term doesn't completely thrill me; it's clear
in context, but not necessarily what someone might go searching for.
{eof:true} would be lovely except we want the default to be yes-EOF but a
On Mon, Mar 26, 2012 at 2:42 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell jsb...@chromium.org
wrote:
Bikeshed: The |continues| term doesn't completely thrill me; it's clear
in context, but not necessarily what someone might go searching for.
On Mon, Mar 26, 2012 at 4:49 PM, Joshua Bell jsb...@chromium.org wrote:
* A |stream| option, per the above
Does this make sense when you're using stream: false to flush the stream?
It's still a streaming operation. I guess it's close enough.
* A |nullTerminator| option eliminates the need
On Mon, Mar 26, 2012 at 2:49 PM, Joshua Bell jsb...@chromium.org wrote:
On Mon, Mar 26, 2012 at 2:42 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell jsb...@chromium.org
wrote:
Bikeshed: The |continues| term doesn't completely thrill me; it's
On Mon, Mar 26, 2012 at 4:12 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 26, 2012 at 4:49 PM, Joshua Bell jsb...@chromium.org wrote:
* A |stream| option, per the above
Does this make sense when you're using stream: false to flush the stream?
It's still a streaming operation. I
On Mon, Mar 26, 2012 at 6:27 PM, Jonas Sicking jo...@sicking.cc wrote:
* It appears that we lost the ability to measure how long a resulting
buffer was going to be and then decode into the buffer. I don't know
if this is an issue.
The theory is that it probably isn't a real performance issue
On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell jsb...@chromium.org wrote:
* We lost the ability to decode from a arraybuffer and see how many
bytes were consumed before a null-terminator was hit. One not terribly
elegant solution would be to add a TextDecoder.decodeWithLength method
which return
On Mon, Mar 26, 2012 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell jsb...@chromium.org wrote:
* We lost the ability to decode from a arraybuffer and see how many
bytes were consumed before a null-terminator was hit. One not terribly
elegant
On Mon, Mar 26, 2012 at 9:11 PM, Kenneth Russell k...@google.com wrote:
The rationale for specifying the string encoding and decoding
functionality outside the typed array specification is to keep the
typed array spec small and easily implementable. The indexed property
getters and setters on
On Mon, Mar 26, 2012 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
Requiring callers to find the null character first, and then use that
will require one additional pass over the encoded binary data though.
That's extremely fast (memchr), and it's probably the fastest thing to do
anyway,
On Mon, Mar 26, 2012 at 6:24 PM, Glenn Maynard gl...@zewt.org wrote:
I guess. It doesn't seem that important, since it's just a few lines of
code. If this is done, I'd suggest that this helper API *not* have any
special support for streaming (not to disallow it, but not to have any
special
On Mon, Mar 26, 2012 at 6:11 PM, Kenneth Russell k...@google.com wrote:
On Mon, Mar 26, 2012 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell jsb...@chromium.org wrote:
* We lost the ability to decode from a arraybuffer and see how many
bytes were
On Mon, Mar 26, 2012 at 6:24 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 26, 2012 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
Requiring callers to find the null character first, and then use that
will require one additional pass over the encoded binary data though.
That's
On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren ann...@opera.com wrote:
Another way would be to have a second optional argument that indicates
whether more bytes are coming (defaults to false), but I'm not sure of the
chances that would be used correctly. The reasons you outline are
On Thu, 22 Mar 2012 03:12:25 +0100, Mark Callow callow_m...@hicorp.co.jp
wrote:
This has encode and decode reversed from my understanding. I regard the
string (wide-char) as the canonical form and the bytes as the encoded
form. This view is reflected in the widely used terminology charset
On Wed, 21 Mar 2012 16:53:36 +0100, Joshua Bell jsb...@chromium.org
wrote:
Just to throw it out there - does anyone feel we can/should offer
asymmetric encode/decode support, i.e. supporting more encodings for
decode operations than for encode operations?
XMLHttpRequest has that. You can
On Thu, 22 Mar 2012 10:19:30 +0100, Anne van Kesteren ann...@opera.com
wrote:
They can use the prefixed variants :-) If we have to use a prefix
String seems better, as Text is a node object in the platform.
Simon pointed out Text as prefix is probably better (it is used elsewhere
in the
On 03/21/2012 04:53 PM, Joshua Bell wrote:
As for the API, how about:
enc = new Encoder(euc-kr)
string1 = enc.encode(bytes1)
string2 = enc.encode(bytes2)
string3 = enc.eof() // might return empty string if all is fine
And similarly you would have
dec = new Decoder(shift_jis)
On Wed, Mar 21, 2012 at 2:42 PM, Anne van Kesteren ann...@opera.com wrote:
As for the API, how about:
enc = new Encoder(euc-kr)
string1 = enc.encode(bytes1)
string2 = enc.encode(bytes2)
string3 = enc.eof() // might return empty string if all is fine
A problem with this is that the
On Thu, 22 Mar 2012 14:47:05 +0100, Glenn Maynard gl...@zewt.org wrote:
A problem with this is that the bugs resulting from not calling eof() are
subtle. The only thing eof() would ever do, I think, is return U+FFFD
characters if there are leftover characters in the internal buffer; if
you
2012/3/22 Anne van Kesteren ann...@opera.com:
As for the API, how about:
enc = new Encoder(euc-kr)
string1 = enc.encode(bytes1)
string2 = enc.encode(bytes2)
string3 = enc.eof() // might return empty string if all is fine
And similarly you would have
dec = new Decoder(shift_jis)
On Tue, Mar 20, 2012 at 10:39 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Mar 20, 2012 at 7:26 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote:
Why are encodings different than other parts of the API where you
indeed have
2012/3/21 Glenn Maynard gl...@zewt.org:
On Tue, Mar 20, 2012 at 12:39 PM, Joshua Bell jsb...@chromium.org wrote:
1. Only support encodings with stateless coding (possibly down to a minimum
of UTF-8)
2. Only provide an API supporting non-streaming coding (i.e. whole
strings/whole buffers)
3.
2012/3/21 Jonas Sicking jo...@sicking.cc:
I'm pretty sure there is consensus for supporting UTF8. UTF8 is
stateful though can be made not stateful by not consuming all
characters and instead forcing the caller to keep the state (in the
form of unconsumed text).
Your use of the word stateful
On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking jo...@sicking.cc wrote:
This leaves us with 2 or 3. So the question is if we should support
streaming or not. I suspect doing so would be worth it.
For XMLHttpRequest it might be, yes.
I think we should expose the same encoding set throughout
On Wed, Mar 21, 2012 at 3:27 AM, Jonas Sicking jo...@sicking.cc wrote:
1) Create an API which forces consumers to do state handling. Probably
leading to people creating wrappers which essentially implement option
3
It's not the same. Please look at how ISO-2022 works: the stream has
On Wed, Mar 21, 2012 at 12:42 PM, Anne van Kesteren ann...@opera.comwrote:
On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking jo...@sicking.cc
wrote:
This leaves us with 2 or 3. So the question is if we should support
streaming or not. I suspect doing so would be worth it.
For
On 3/21/2012 8:53 AM, Joshua Bell wrote:
On Wed, Mar 21, 2012 at 12:42 PM, Anne van Kesterenann...@opera.comwrote:
On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sickingjo...@sicking.cc
wrote:
This leaves us with 2 or 3. So the question is if we should support
streaming or not. I suspect
On 22/03/2012 04:42, Anne van Kesteren wrote:
...
As for the API, how about:
enc = new Encoder(euc-kr)
string1 = enc.encode(bytes1)
string2 = enc.encode(bytes2)
string3 = enc.eof() // might return empty string if all is fine
And similarly you would have
dec = new
On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote:
Why are encodings different than other parts of the API where you
indeed have to know what works and what doesn't.
Do you memorize lists of encodings? I certainly don't. I look them up as
needed.
UTF8 is stateful, so I
On Tue, Mar 20, 2012 at 7:26 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote:
Why are encodings different than other parts of the API where you
indeed have to know what works and what doesn't.
Do you memorize lists of
On Tue, Mar 20, 2012 at 12:39 PM, Joshua Bell jsb...@chromium.org wrote:
1. Only support encodings with stateless coding (possibly down to a minimum
of UTF-8)
2. Only provide an API supporting non-streaming coding (i.e. whole
strings/whole buffers)
3. Expand the API to return encoder/decoder
On 17/03/2012 08:19, Boris Zbarsky wrote:
I think that trying to get web developers to do this right is a lost
cause, esp. because none of them (to a good approximation) have any
big-endian systems to test on.
On what do you base this oft-repeated assertion? ARM CPUs can work
either way. I
On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking jo...@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
On Mon, Mar 19, 2012 at 7:00 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking jo...@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
On Mon, Mar 19, 2012 at 12:46 PM, Joshua Bell jsb...@chromium.org wrote:
I have edited the proposal to base the list of encodings on
http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html - is there any
reason that would not be sufficient or appropriate? (this appears to be a
superset of
On Mon, Mar 19, 2012 at 5:10 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 19, 2012 at 5:54 PM, Jonas Sicking jo...@sicking.cc wrote:
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
On Mon, Mar 19, 2012 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
What value are we adding, and to whom, by keeping the list the
smallest it can be, even when that means keeping the lists of
supported encodings different between different APIs?
Not needlessly extending support for
On Mon, Mar 19, 2012 at 8:14 PM, Glenn Maynard gl...@zewt.org wrote:
If this is the only reason that'd all have to be specified, that's
probably another reason to consider it...
(Well, there's form data either way. At least encoding is probably easier
to spec, since it only has to deal with
On Mon, Mar 19, 2012 at 6:14 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 19, 2012 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
What value are we adding, and to whom, by keeping the list the
smallest it can be, even when that means keeping the lists of
supported encodings
On Thu, Mar 15, 2012 at 5:20 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 15, 2012 at 6:51 PM, Jonas Sicking jo...@sicking.cc wrote:
What's the use-case for the stringLength function? You can't decode
into an existing datastructure anyway, so you're ultimately forced to
call decode at
On Fri, Mar 16, 2012 at 9:19 AM, Joshua Bell jsb...@chromium.org wrote:
And just to be clear, the use case is decoding data formats where string
fields are variable length null terminated.
... and the spec should include normative guidance that length-prefixing is
strongly recommended for
On Fri, Mar 16, 2012 at 11:19 AM, Joshua Bell jsb...@chromium.org wrote:
And just to be clear, the use case is decoding data formats where string
fields are variable length null terminated.
A concrete example is ZIP central directories.
I think we want both encoding and destination to be
On Fri, 16 Mar 2012, Glenn Maynard wrote:
On Fri, Mar 16, 2012 at 11:19 AM, Joshua Bell jsb...@chromium.org wrote:
And just to be clear, the use case is decoding data formats where string
fields are variable length null terminated.
A concrete example is ZIP central directories.
I think
On Fri, Mar 16, 2012 at 10:35 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Mar 16, 2012 at 11:19 AM, Joshua Bell jsb...@chromium.org wrote:
... where output === view if view is supplied, otherwise a new Uint8Array
(or Uint8ClampedArray??)
Uint8Array is correct. (Uint8ClampedArray is
On 3/16/12 5:12 PM, Joshua Bell wrote:
FYI, there was some follow up IRC conversation on this. With Typed Arrays
as currently specified - that is, that Uint16Array has platform endianness
For what it's worth, it seems like this is something we should seriously
consider changing so as to make
On 3/16/2012 2:17 PM, Boris Zbarsky wrote:
On 3/16/12 5:12 PM, Joshua Bell wrote:
FYI, there was some follow up IRC conversation on this. With Typed
Arrays
as currently specified - that is, that Uint16Array has platform
endianness
For what it's worth, it seems like this is something we
On Fri, 16 Mar 2012, Charles Pritchard wrote:
On 3/16/2012 2:17 PM, Boris Zbarsky wrote:
On 3/16/12 5:12 PM, Joshua Bell wrote:
FYI, there was some follow up IRC conversation on this. With Typed Arrays
as currently specified - that is, that Uint16Array has platform endianness
For what it's
On Fri, Mar 16, 2012 at 4:44 PM, Charles Pritchard ch...@jumis.com wrote:
The DataView set of methods already does this work. The raw arrays are
supposed to have platform endianness.
That's wrong. This is web API design 101; everyone should know better than
this by now. Exposing platform
On 3/16/2012 3:26 PM, Glenn Maynard wrote:
On Fri, Mar 16, 2012 at 4:44 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
The DataView set of methods already does this work. The raw arrays
are supposed to have platform endianness.
That's wrong. This is web API
On 3/16/12 5:44 PM, Charles Pritchard wrote:
The DataView set of methods already does this work. The raw arrays are
supposed to have platform endianness.
I haven't seen anyone actually using the DataView stuff in practice, or
presenting it to developers much...
If you see some evangelists
On 3/16/12 5:25 PM, Brandon Jones wrote:
Everyone knows that typed arrays /can/ be Big Endian, but I'm not aware
of any devices available right now that support WebGL that are.
I believe that recent Firefox on a SPARC processor would fit that
description. Of course the number of web
On Fri, Mar 16, 2012 at 9:19 AM, Joshua Bell jsb...@chromium.org wrote:
On Thu, Mar 15, 2012 at 5:20 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Mar 15, 2012 at 6:51 PM, Jonas Sicking jo...@sicking.cc wrote:
What's the use-case for the stringLength function? You can't decode
into an
On 3/16/2012 4:25 PM, Boris Zbarsky wrote:
On 3/16/12 5:25 PM, Brandon Jones wrote:
Everyone knows that typed arrays /can/ be Big Endian, but I'm not aware
of any devices available right now that support WebGL that are.
I believe that recent Firefox on a SPARC processor would fit that
On Fri, Mar 16, 2012 at 4:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/16/12 5:25 PM, Brandon Jones wrote:
Everyone knows that typed arrays /can/ be Big Endian, but I'm not aware
of any devices available right now that support WebGL that are.
I believe that recent Firefox on a SPARC
On 3/16/12 7:43 PM, James Robinson wrote:
You can s/web developers/users/ and the statement would still apply,
wouldn't it?
Sure, but so what?
The upshot is that people are writing code that assumes little-endian
hardware all over. We should just clearly make the spec say that that's
what
On 3/16/2012 5:25 PM, Boris Zbarsky wrote:
On 3/16/12 7:43 PM, James Robinson wrote:
You can s/web developers/users/ and the statement would still apply,
wouldn't it?
Sure, but so what?
The upshot is that people are writing code that assumes little-endian
hardware all over. We should just
On Wed, 14 Mar 2012 23:53:12 +0100, Glenn Maynard gl...@zewt.org wrote:
On Wed, Mar 14, 2012 at 6:52 AM, Anne van Kesteren ann...@opera.com
wrote:
If we can make it a deterministic, unchanging, and defined algorithm, I
think that would actually be acceptable. And ideally we do define that
On Wed, Mar 14, 2012 at 3:33 PM, Joshua Bell jsb...@chromium.org wrote:
FYI, I've updated http://wiki.whatwg.org/wiki/StringEncoding
A few comments:
What's the use-case for the stringLength function? You can't decode
into an existing datastructure anyway, so you're ultimately forced to
call
On Thu, Mar 15, 2012 at 6:51 PM, Jonas Sicking jo...@sicking.cc wrote:
What's the use-case for the stringLength function? You can't decode
into an existing datastructure anyway, so you're ultimately forced to
call decode at which point the stringLength function hasn't helped
you.
On Wed, 14 Mar 2012 01:01:42 +0100, Ian Hickson i...@hixie.ch wrote:
Seems reasonable. If we have specific use cases for non-UTF-8 encodings,
I agree we should support them; if that's the case, we should survey
those
use cases to work out what the set of encodings we need is, and add just
Hi,
On Wed, Mar 14, 2012 at 06:49, Jonas Sicking jo...@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
On 03/14/2012 12:38 AM, Tab Atkins Jr. wrote:
On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynardgl...@zewt.org wrote:
The API on that wiki page is a reasonable start. For the same reasons that
we discussed in a recent thread (
On Wed, 14 Mar 2012 00:50:43 +0100, Joshua Bell jsb...@chromium.org
wrote:
For both of the above: initially suggested use cases included parsing
data as esoteric as ID3 tags in MP3 files, where encoding unspecified
and is
guessed at by decoders, and includes non-Unicode encodings. It was
FYI, I've updated http://wiki.whatwg.org/wiki/StringEncoding
* Rewritten in terms of Anne's Encoding spec and WebIDL, for algorithms,
encodings, and encoding selection, which greatly simplifies the spec. This
implicitly adds support for all of the other encodings defined therein - we
may still
On Tue, Mar 13, 2012 at 9:47 PM, John Tamplin j...@google.com wrote:
I am fine with strongly suggesting that only UTF8 be used for new things,
but leaving out legacy support will severely limit the utility of this
library.
Not all limitations are bad, and I'd disagree with seriously.
At a
On Wed, Mar 14, 2012 at 3:53 PM, Glenn Maynard gl...@zewt.org wrote:
It's more than a naming problem. With this string API, one side of the
conversion is always a DOMString. Base64 conversion wants
ArrayBuffer-ArrayBuffer conversions, so it would belong in a separate API.
Huh. The
Hi All,
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
On Tue, Mar 13, 2012 at 3:49 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
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
On Tue, 13 Mar 2012, Jonas Sicking 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).
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
On Tue, Mar 13, 2012 at 3:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Mar 13, 2012 at 3:49 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Something that has come up a couple of times with content authors
lately has been the desire to convert an ArrayBuffer (or part thereof)
On Tue, Mar 13, 2012 at 4:08 PM, Kenneth Russell k...@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
On Tue, Mar 13, 2012 at 5:49 PM, Jonas Sicking jo...@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
On Tue, Mar 13, 2012 at 6:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 13, 2012 at 4:08 PM, Kenneth Russell k...@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
On Tue, 13 Mar 2012, Jonas Sicking wrote:
Unfortunately I suspect getting anything added on the String object will
take a few years given that it's too late to get into ES6 (and in any
case I suspect adding ArrayBuffer dependencies to ES6 would be
controversial).
We can just define it
On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 13, 2012 at 5:49 PM, Jonas Sicking jo...@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
On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 13, 2012 at 5:49 PM, Jonas Sicking jo...@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
On Tue, 13 Mar 2012, Joshua Bell wrote:
On Tue, Mar 13, 2012 at 4:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 13, 2012 at 4:08 PM, Kenneth Russell k...@google.com
wrote:
Joshua Bell has been working on a string encoding and decoding API
that supports the needed encodings,
On Tue, 13 Mar 2012, Joshua Bell wrote:
WHATWG makes sense, I just hadn't gotten around to shopping for a home.
(Administrivia: Is there need to propose a charter addition?)
You're welcome to use the WHATWG list for this. Charters are pointless and
there's no need to worry about them here.
On Tue, Mar 13, 2012 at 4:08 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 13, 2012 at 3:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Mar 13, 2012 at 3:49 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Something that has come up a couple of times with content authors
On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynard gl...@zewt.org wrote:
The API on that wiki page is a reasonable start. For the same reasons that
we discussed in a recent thread (
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1589.html),
conversion errors should use replacement
On Tue, 13 Mar 2012, Joshua Bell wrote:
For both of the above: initially suggested use cases included parsing
data as esoteric as ID3 tags in MP3 files, where encoding unspecified
and is guessed at by decoders, and includes non-Unicode encodings. It
was suggested that the encoding
Using Views instead of specifying the offset and length sounds good.
On Tue, Mar 13, 2012 at 6:28 PM, Ian Hickson i...@hixie.ch wrote:
- What's the use case for supporting anything but UTF-8?
Other Unicode encodings may be useful, to decode existing file formats
containing (most likely at a
On Tue, Mar 13, 2012 at 8:19 PM, Glenn Maynard gl...@zewt.org wrote:
Using Views instead of specifying the offset and length sounds good.
On Tue, Mar 13, 2012 at 6:28 PM, Ian Hickson i...@hixie.ch wrote:
- What's the use case for supporting anything but UTF-8?
Other Unicode encodings
97 matches
Mail list logo
