W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2010

Re: Adoption of the Typed Array Specification

From: Erik Corry <erik.corry@gmail.com>
Date: Tue, 18 May 2010 09:22:54 +0200
Message-ID: <AANLkTimMFrF7JtIrEgz3EpUU24lx1L_U8fu_bTZT09B0@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>, "arun@mozilla.com" <arun@mozilla.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
2010/5/18 Kenneth Russell <kbr@google.com>:
> On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock
> <Allen.Wirfs-Brock@microsoft.com> wrote:
>>> Vladimir Vukicevic vladimir@mozilla.com said:
>>>However, another consideration is that the WebGL spec isn't ES specific,
>>> and yet has to depend on typed arrays.  So perhaps we're really talking
>>> about two different specs: a main typed array spec that uses Web IDL and can
>>> be implemented generically in any language, as well as a separate spec
>>> describing ES types that happen to fulfill the requirements of typed arrays.
>> If that is a concern, how do you expect these interfaces to work with other
>> languages.  In a C++ binding are the view objects and the buffer objects
>> still going be distinct objects or are you expect to merge them into native
>> C++ objects.   I think that there is a pretty fundamental question here:
>> does your (and similar) application need to expose binary buffers that exist
>> natively in the  implementation technology of your subsystem and which can
>> be interchange among multiple client languages.  Or, are you able and
>> willing to directly work with native JavaScript buffer objects (assuming
>> that such things exist) even it that a less natural form of access on your
>> part.  In the first case, “host objects” may be exactly what you need.  If
>> the second is what you would like, then we probably need a EcmaScript
>> extension.
> Using hypothetical native JavaScript buffer objects would be
> compatible with our current relatively simple use of TypedArrays.
> However, we have begun to explore more advanced use cases including
> sharing TypedArrays among web workers, and between ECMAScript and
> browser plugins. In these situations, if we were to use native
> JavaScript buffer objects, we would need to specify additional
> behavior for the objects.

This looks like a can of worms to me.  Shared buffers break with the
shared-nothing and message-passing paradigms and necessitate
synchronization primitives.

> In the Java platform, the NIO buffer classes provide similar
> functionality, and provide a bridge to the outside world. The Java
> APIs [1] specify how values can be fetched and stored in the buffers.
> A few entry points in the Java Native Interface [2] specify how
> external C code can wrap a region of memory in a NIO buffer and
> thereby expose it to Java. If it were possible to specify similar
> functionality in an ECMAScript extension, I think it would enable all
> of the use cases mentioned above.
> -Ken
> [1] http://java.sun.com/javase/6/docs/api/java/nio/package-summary.html
> [2] http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
Received on Tuesday, 18 May 2010 11:16:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC