- From: Kenneth Russell <kbr@google.com>
- Date: Mon, 17 May 2010 17:06:48 -0700
- To: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>
- Cc: Vladimir Vukicevic <vladimir@mozilla.com>, "Mark S. Miller" <erights@google.com>, "arun@mozilla.com" <arun@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
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. 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
Received on Tuesday, 18 May 2010 00:07:48 UTC