Hosting modules is relatively straightforward, if a little cumbersome. Each module must include a manifest written in JSON that identifies the various files associated with it. The module must be invoked using an
Off and stumbling with NaCl
To see NaCl apps in action, you need a browser that supports Native Client. For now, that means Chrome 10 or later, and you need to explicitly enable NaCl, either with a command-line option or through Chrome's experimental features panel. Once NaCl is enabled, Chrome warns you that security and stability will suffer -- don't try this at home, kids.
One gotcha is that while NaCl modules are platform-independent, they are not architecture-independent. All the examples included with the SDK compile to two separate .nexe files: one for x86 and another for x64. Google has said it plans to have NaCl running on Chrome OS devices at some point, so presumably you'll need to maintain a third binary for the ARM architecture if you want your module to run on those.
As it stands, you can't run 32-bit modules on a 64-bit PC. NaCl detects the architecture automatically and requests the appropriate version of the module. If it's not found on the server, the application fails. Merely commenting out the path to the 64-bit module in the manifest file was enough to make the demos fail on my Windows 7 x64 machine; trying to fool the system by specifying the same binary for both architectures didn't work either. The really interesting thing was that the version of Chrome I was using for testing was itself a 32-bit application; even so, NaCl would only accept module binaries built for x64.