I all!
I'm the author of the API.
Stefano (alias fusionchess)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Jan 10, 2014 at 7:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[...] it might be reasonable to have a solution that isn't tied to a specific
environment.
Agreed. I have argued the same for URL parsing
http://url.spec.whatwg.org/ at some point.
As for the API in the Encoding
On Fri, Jan 10, 2014 at 9:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
OK, so specify ISO-8859-1, if that's what you're really doing.
Note that iso-8859-1 maps to windows-1252. There is an open bug on
exposing a label to the API that has the real iso-8859-1 behavior:
I think based on bugs and bz's advice the Dwayne has been misled by bad
old pre-WebIDL API in Gecko -- there's no reason to do any
string-viewing here. Certainly not punning bytes as points in a
character set encoding.
/be
Anne van Kesteren mailto:ann...@annevk.nl
January 11, 2014 8:27 AM
On Jan 11, 2014, at 6:13 AM, Anne van Kesteren wrote:
On Fri, Jan 10, 2014 at 7:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[...] it might be reasonable to have a solution that isn't tied to a
specific environment.
Agreed. I have argued the same for URL parsing
On Sat, Jan 11, 2014 at 5:27 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
There are a couple places where a string such as EncodingError is thrown.
We'd never do that and would use either TypeError or RangeError.
If you follow the link for throw, you'll find it's a DOMException.
The
Another nit: the definition of ASCII whitespace is different from the
definition of whitespace used by String.prototype.trim [1]. That means that an
implementation of this spec. that was implemented using JS couldn't use
S.p.trim to process labels as described in the spec.
[1]:
Allen Wirfs-Brock wrote:
Another nit: the definition of ASCII whitespace is different from
the definition of whitespace used by String.prototype.trim [1]. That
means that an implementation of this spec. that was implemented using
JS couldn't use S.p.trim to process labels as described in the
On Sat, Jan 11, 2014 at 5:57 PM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
Another nit: the definition of ASCII whitespace is different from the
definition of whitespace used by String.prototype.trim [1]. That means that
an implementation of this spec. that was
On Jan 11, 2014, at 10:07 AM, Anne van Kesteren wrote:
On Sat, Jan 11, 2014 at 5:57 PM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
Another nit: the definition of ASCII whitespace is different from the
definition of whitespace used by String.prototype.trim [1]. That
On Sat, Jan 11, 2014 at 6:37 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I'm only talking about this specification and what it takes to decouple it
from web platform dependencies. In this case, ASCII whitespace seems to only
be used in processing the label parameter passed to the
On Jan 11, 2014, at 10:52 AM, Anne van Kesteren wrote:
On Sat, Jan 11, 2014 at 6:37 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I'm only talking about this specification and what it takes to decouple it
from web platform dependencies. In this case, ASCII whitespace seems to
only
https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that StringView
[1] over ArrayBuffers be added to ES.
The current StringView proposal is a WebIDL based design and not particularly
integrated into the ES6 Typed Array support, the ES6 Unicode support, or the
post ES6 Binary Data
On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that
StringView [1] over ArrayBuffers be added to ES.
[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays/StringView
Where is
On Fri, Jan 10, 2014 at 10:26 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that
StringView [1] over ArrayBuffers be added to ES.
[1]
On Jan 10, 2014, at 10:26 AM, Anne van Kesteren wrote:
On Fri, Jan 10, 2014 at 6:22 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
https://bugs.ecmascript.org/show_bug.cgi?id=1557 is a request that
StringView [1] over ArrayBuffers be added to ES.
[1]
Kenneth Russell wrote:
Adding a StringView to Typed Arrays would bring along all of the
complexities of character set encoding and decoding to the Typed Array
definitions. Typed Arrays were designed to be small, simple, and
comprehensible enough that they would be easily implementable and
I disagree. I think this should progress. It doesn't have to add any
additional functionality to Typed Arrays. As it stands I would consider it
a replacement for the purposes of TextEncoder and TextDecoder APIs.
Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid
encoding
On 1/10/14 3:47 PM, Dwayne wrote:
Currently the Mozilla TextDecoder Web API does not accept ASCII as a
valid encoding option
I'm curious. What would you expect such an option to do? Byte-inflate
like ISO-8859-1? Byte-inflate but throw on bytes with values 127?
Act as a synonym for
Dwayne wrote:
Currently the Mozilla TextDecoder Web API does not accept ASCII as a
valid encoding option and defaults to UTF-8, if left unspecified.
That's a feature.
The '90s are over, let's not go back.
Why do you want ASCII, and what do you do with it?
/be
On Fri, Jan 10, 2014 at 3:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I'm curious. What would you expect such an option to do? Byte-inflate
like ISO-8859-1? Byte-inflate but throw on bytes with values 127? Act as
a synonym for ISO-8859-9? Something else?
Exactly how StringView handles
UDP Datagrams.
On Fri, Jan 10, 2014 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote:
Dwayne wrote:
Currently the Mozilla TextDecoder Web API does not accept ASCII as a
valid encoding option and defaults to UTF-8, if left unspecified.
That's a feature.
The '90s are over, let's not go
On 1/10/14 4:29 PM, Dwayne wrote:
Exactly how StringView handles the option now. If I generate a random
string using byte values then each char in that string should correspond
to a single byte when specifying the ISO-8859-1.
OK, so specify ISO-8859-1, if that's what you're really doing. Or
I mean char code points in the range (0-255) a byte. Use the desired
terminology or name.
Primarily because of this bug - Expose raw data on UDP socket messages:
https://bugzilla.mozilla.org/show_bug.cgi?id=952927
I generate a random string using code points that I eventually convert to
bytes.
Dwayne wrote:
UDP Datagrams.
Use a Uint8Array and string decoding/encoding API. Browsers have to copy
anyway, you're not optimizing by using the (soon to be dead, I hope)
StringView.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
No joke. But as far as optimization goes I'm limited. You wrote the book so
thanks for at least hearing me out. ;)
On Fri, Jan 10, 2014 at 4:07 PM, Brendan Eich bren...@mozilla.com wrote:
Dwayne wrote:
UDP Datagrams.
Use a Uint8Array and string decoding/encoding API. Browsers have to copy
Dwayne wrote:
Primarily because of this bug - Expose raw data on UDP socket
messages: https://bugzilla.mozilla.org/show_bug.cgi?id=952927
Answering for bz: why do you need string-views or string-anythings to
wrangle bytes in and out of a Uint8Array? Can you show some code?
/be
Compensate the lack of rawData property -- Bug 952927
Buffer is a Uint8Array which has non standard methods on its prototype
using a WeakMap technique. --
This module will be used with BitTorrent PWP as well so its definitely
necessary.
On 1/10/14 10:46 PM, Dwayne wrote:
Compensate the lack of rawData property -- Bug 952927
Sure, but that should be fixed by adding such a property in this case,
no? The only reason this is using a string is because it's using a
somewhat braindead IDL (_way_ more braindead for purposes of JS
29 matches
Mail list logo
