3 ms·
Google has already indirectly "extended" Native Client with native 3D graphics using their O3D API (http://code.google.com/apis/o3d/ http://code.google.com/apis
by niktechx 17y ago
Google has already indirectly "extended" Native Client with native 3D graphics using their O3D API (http://code.google.com/apis/o3d/ http://code.google.com/apis/o3d/). It's just a matter of time until someone codes up a library to expose that API through JS interop in Native Client.
I think we can expect very close integration of Native Client into the Chrome OS as soon as or right after it goes public. To the level of accessing hardware ports to control external devices right from your Native Client web-app.
Imagine drivers that get loaded and updated on-the-fly. Of course, Google will have to implement a smart security mechanism (along the lines of RSA authentication for dynamic device/driver coupling) and provide a way for device manufacturers to register their driver's public keys with Chrome OS.
- Raphael 17y agoBut will Native Client work on ARM?
- niktechx 17y agoYes: http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html http://google-code-updates.blogspot.com/2008/12/native-clien...
- pavlov 17y agoI think Native Client's environment is constrained enough that it would be feasible to implement JIT translation between architectures (i.e. x86 -> ARM). ISA translation tech is already widespread: a company called Transitive has been quite successful in offering translation products for Unix vendors who have needed to transition their customers to a new architecture (most visibly they provided the PPC->x86 translation engine for Apple's "Rosetta"). With Native Client, the translation ought to be made easier by the structural limitations that are imposed on NaCl modules primarily for security purposes -- to use a natural language analogy, it's easier to translate a text if you know all the words originate from a certain dictionary.