Native client in the Chrome Web App store |
Written by Harry Fairhead | |||
Monday, 22 August 2011 | |||
NaCL based apps are now allowed in the Chrome Web App Store beta channel and will be moved into the full Chrome Web App store when Chrome 14 is released The romance with all things C++ seems to be going full steam ahead, at Google at least. The latest news is that native apps, i.e. NaCL based apps, are now allowed in the Chrome Web App Store beta channel. When Chrome 14 makes it to the stable channel then native web apps will be moved into the full Chrome Web App store providing access to an estimated 160 million Chrome users. What this means is that Chrome native code or NaCL applications have not only made it into Chrome as a fully supported sub-system, but Google is happy to promote their use by letting us create apps and sell them.In case you have missed the idea, native apps are written in C/C++ and compile down to machine code, i.e. there are no virtual machines to get in they way of your efficiency considerations. The native client uses the Pepper library to interface with the HTML and run in a two-layer sandbox for security. The native client sandbox sits inside the usual Chrome sandbox and stops access to the underlying OS API. What this means is that Pepper has to yet again reinvent the wheel in the interests of security. Currently Pepper supports 2D graphics, audio, URL fetching and sandboxed access to the local file store and a connection with JavaScript running in the browser. Future releases will also support hardware accelerated 3D graphics, web sockets and just about anything else they can squeeze in.
If you think about it for a minute you will see that what is going on is the implementation of another operating system inside the browser which, of course, is running inside the native operating system. If you think this is slightly crazy, the next stage in the development of NaCl is go to portable with PNaCl, pronounced Pinnacle. NaCl applications can run on different native operating systems as long as they run on the same machine architecture. For example, an NaCl app can run under Windows or Linux say running on an 86x architecture - the reason is, of course that the "operating system" as far as the app is concerned is the Chrome browser. What they cannot do is run on a Chrome browser running on, say, an ARM architecture - because the native code is different. The big idea is to find a way to make native apps not only OS independent but machine architecture independent. This is the final stage in the iteration. Now the C/C++ and other languages will be compiled to a "bitcode" for the Low Level Virtual Machine, LLVM. If you think is is the final straw, after all the whole point of NaCl is to avoid having to use a virtual machine and here we are seemingly introducing a virtual machine, then the good news is that the code is compiled from bitcode to the native code of the machine in question. The progress is sort-of-logical but it still looks like a set of nested Russian dolls. NaCl was invented to give browser programmers access to native code and the speed that this offers, but native code isn't portable and, with ARM and alternative architectures on the scene, this isn't good. So what do we do - invent an intermediate language and a way of JIT compiling it. Of course this mirrors exactly the steps that led to languages such as Java and byte code some years ago. There is also the issue that NaCl and PNaCl are custom to Chrome and hence another brick in the browser wars. At least things are getting interesting...
More informationChrome beta adds native client
If you would like to be informed about new articles on I Programmer you can either follow us on Twitter or Facebook or you can subscribe to our weekly newsletter.
|
|||
Last Updated ( Monday, 22 August 2011 ) |