How about _recursive_ VM/JITs *beneath* the level that HTML/JS is implemented.
So the "browser" that ships only supports this recursive VM. HTML is an application of this that can be evolved by open source at internet scale / time. Web pages can point at a specific HTML implementation or a general redirector like google apis to get the commonly agreed standard version. Other containers/'plugins', Squeak, Flash, Java run as VMs, can run their native bytecode/images but also, potentially, expose the VM interface up again. Nesting VMs is useful also. Though you won't spare the use-case any love, Flash video players often load multiple ads SDKs, an arrangement that could benefit from isolation, i.e. browser-more-like-OS. If the top and bottom VM interfaces are the same then we can stack them (as well as nesting them). Base VM would have exokernel / NaCL like exposure of the native capabilities of the device. Exokernel & FluxOS have some nifty tricks to punch through layers so performance is not so impacted by stacking. An intermediate VM layer could provide ISA / hardware abstraction so that everything above that looks the same. I re-read history of Smalltalk recently and was reminded of this from Alan, 'Bob Barton, the main designer of the B5000 and a professor at Utah had said in one of his talks a few days earlier: "The basic principal of recursive design is to make the parts have the same power as the whole." For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures. Why not divide it up into little computers, as time sharing was starting to? But not in dozens. Why not thousands of them, each simulating a useful structure?' Toby On 9 June 2011 10:25, Josh Gargus <[email protected]> wrote: > > On Jun 9, 2011, at 2:04 AM, BGB wrote: > >> On 6/9/2011 12:56 AM, Josh Gargus wrote: >>> >>> >>> On May 31, 2011, at 7:30 AM, Alan Kay wrote: >>> >>>> Hi Cornelius >>>> >>>> There are lots of egregiously wrong things in the web design. Perhaps one >>>> of the simplest is that the browser folks have lacked the perspective to >>>> see that the browser is not like an application, but like an OS. i.e. what >>>> it really needs to do is to take in and run foreign code (including low >>>> level code) safely and coordinate outputs to the screen (Google is just >>>> starting to realize this with NaCl after much prodding and beating.) >>>> >>>> I think everyone can see the implications of these two perspectives and >>>> what they enable or block >>> >>> Some of the implications, anyway. The benefits of the OS-perspective are >>> clear. Once it hits its stride, there will be no (technical) barriers to >>> deploying the sorts of systems that we talk about here >>> (Croquet-Worlds-Frank-OMeta-whatnot). Others will be doing their own cool >>> things, and there will be much creativity and innovation. >>> >>> However, elsewhere in this thread it is noted that the HTML-web is >>> structured-enough to be indexable, mashupable, and so forth. It makes me >>> wonder: is there a risk that the searchability, etc. of the web will be >>> degraded by the appearance of a number of mutually-incompatible >>> better-than-HTML web technologies? Probably not... in the worst case, >>> someone who wants to be searchable can also publish in the "legacy" format. >>> >>> However, can we do better than that? I guess the answer depends on which >>> aspect of the status quo we're trying to improve on (searchability, >>> mashups, etc). For search, there must be plenty of technologies that can >>> improve on HTML by decoupling search-metadata from presentation/interaction >>> (such as OpenSearch, mentioned elsewhere in this thread). Mashups seem >>> harder... maybe it needs to happen organically as some of the >>> newly-possible systems find themselves converging in some areas. >>> >>> But I'm not writing because I know the answers, but rather the opposite. >>> What do you think? >>> >> >> hmm... it is a mystery.... >> >> actually, possibly a relevant question here, would be why Java applets >> largely fell on their face, but Flash largely took off (in all its uses from >> YouTube to "Punch The Monkey"...). >> >> but, yeah, there is another downside to deploying ones' technology in a >> browser: >> writing browser plug-ins... >> >> >> and, for browser-as-OS, what exactly will this mean, technically?... >> network-based filesystem and client-side binaries and virtual processes?... >> like, say, if one runs a tiny sand-boxed Unix-like system inside the >> browser, then push or pull binary files, which are executed, and may perform >> tasks?... > > > This isn't quite what I had in mind. Perhaps "hypervisor" is better than > "OS" to describe what I'm talking about, and I believe Alan too: a > thin-as-possible platform that provides access to computing resources such as > end-user I/O (mouse, multitouch, speakers, display, webcam, etc.), CPU/GPU, > local persistant storage, and network. Just enough to enable others to run > OSes on top of this hypervisor. > > If it tickles you fancy, then by all means use it to run a sand-boxed Unix. > Undoubtedly someone will; witness the cool hack to run Linux in the browser, > accomplished by writing an x86 emulator in Javascript > (http://bellard.org/jslinux/). > > However, such a hypervisor will also host more ambitious OSes, for example, > platforms for persistent capability-secure peer-to-peer real-time > collaborative end-use-scriptable augmented-reality environments. (again, > trying to use word-associations to roughly sketch what I'm referring to, as I > did earlier with "Croquet-Worlds-Frank-OMeta-whatnot"). > > Does this make my original question clearer? > > Cheers, > Josh > > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
