- From: Erik Corry <erik.corry@gmail.com>
- Date: Tue, 18 May 2010 09:22:54 +0200
- 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