3 ms·
Discussions of technical feasibility aside, getting a sufficiently large installed base to make this interesting is (as usual) the "fun" part; your plan for get
by Hoff 16y ago
Discussions of technical feasibility aside, getting a sufficiently large installed base to make this interesting is (as usual) the "fun" part; your plan for getting to critical mass against an available and "good enough" solution.
As for previous bytecode approaches to consider, there are the Lisp Machines, or the Burroughs B5000 Algol box, or the EFI byte code (EBC) interpreter and the EBC I/O drivers, or UCSD pCode, or all the gonzo things you could do with the VAX User Writable Control Store, the JITs underneath Java and Lua and other languages, or...
And HTTP is printable, which means you're working within character-encoding constraints or with escapements.
There are the not-inconsequential security requirements.
And then there's the question of how a provider might make money with this, if you're not undertaking this effort for free.
Have at...
- klync 16y agoCongratulations on being the only person in this thread with two feet on the ground. Interesting discussion, nonetheless. But purely academic.
- pjscott 16y agoSince Google is actually working on this, I would read their PNaCL paper before calling the discussion "purely academic": http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf Summary: Send LLVM bytecode to the browser, and enforce sandboxing by inspecting the compiled code.