W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Binary API Design Questions

From: Kris Kowal <kris.kowal@cixar.com>
Date: Tue, 1 Dec 2009 15:45:28 -0800
Message-ID: <ef3cdbd90912011545p5e34ec73g9aedabf014d38a8a@mail.gmail.com>
To: public-script-coord@w3.org, es-discuss Steen <es-discuss@mozilla.org>, commonjs@googlegroups.com
[+es-discuss, w3c, commonjs]

I have posted a new draft proposal.

http://wiki.commonjs.org/wiki/Binary/D

Discussion so far has illuminated the dimensions for the general
approach to such an API.

1. Whether to support both mutable and immutable binary data types.
2. Whether to mutables should be modeled after Array and immutables after String
3. Whether to support bit quantized types or methods
4. Whether to support charset encoding/decoding with methods
5. Whether to support radix encoding/decoding with methods
6. Whether to support struct packing/unpacking/calcsizing with methods
7. Whether to explicitly or implicitly manage contiguous memory ownership
8. Whether to target native support: short term, long term, never
(This affects whether to require [[Get]], [[Put]], ==, and ===
operators to be revised to handle bytes alongside character strings,
or whether to establish a precedent for methods like "equals")

The biggest collective question is whether, and in what time-frame,
binary data would be supported as a primordial or primordials
analogous to String and Array.  CommonJS is naturally anxious to
produce a specification that can be stubbed in the short term.  For
the CommonJS group, the bit question then is future-compatibiilty.
Should we strive to effect usage patterns that would be conducive of
an eventual native implementation?  For example, should "new
ByteString" be required to return a boxed type?  Should it throw an
exception in the short term so that people won't write code that
expects an un-boxed object to be constructed?  Can we expect that
typeof ByteString() will be "object" in a future ECMA or W3C
specification?

Kris Kowal
Received on Tuesday, 1 December 2009 23:53:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC