Here are some ideas on things to do with this package. Many of them will need extensions to the base system, and many aren't worthwhile until it's been proven useful for semi-real apps. I have somewhat less sketchy notions about these things than is written down here -- I'd be happy to talk about them. Mainly I'm putting this here in hopes of sparking ideas and getting people interested in hacking stuff. Make a kernel module for running Idel stuff. Use it for in-kernel packet processing. [Luke is thinking about this.] Or for a high-performance dynamic-content webserver. A more far-reaching project would be to give Linux something like the loadable extensions in SPIN -- allow the user to supply scheduler code, etc. Make a portable algorithm-neutral decompression suite and some compressors to go with it. [Ryan wanted to start this one.] Make a mobile-agents system. See Nelson Minar's thesis for some simple beginnings. See below for some more applications of mobile code. Then a more ambitious system: a general-purpose idle-time sopper-upper with computational markets -- maybe working with Mojo Nation? Other companies to check out: Entropia www.entropia.com United Devices www.uniteddevices.com Parabon www.parabon.com Popular Power www.popularpower.com Nope, none of them looks promising... ``proprietary, patent-pending technology'', etc. Or they want you to contact them just to find out how you might run your program on their platform. Let's kill 'em. :) Network management using mobile code for monitoring, etc. Needs a standard interface to SNMP agents -- is there one already? A genetic-algorithms package exploiting our future x86 jit backend. This needs a fast code-generation interface instead of object files. Make an active-packets system -- where the network protocol at each node is just ``interpret the program at the head of the packet''. This will need code compression similar to what the above decompression suite will use. Write a Idel backend for a Scheme compiler -- Larceny seems the most promising. Or maybe Scheme48, but you probably want to avoid the C-based ones. This raises issues like how to support garbage collection; C-- might show the way. Write a Idel backend for a C compiler. How much work is porting the standard libraries? Can you do something like register allocation without knowing how many registers the physical machine will have? Make a language-neutral extensible environment like emacs -- giving similar flexibility and robustness without hardwiring a particular programming language into it or incurring the shocking overhead of Unix IPC. Does mobile code add anything interesting to the design of an editor? (emacs was designed before mobile code.) With lots of work this could grow into an OS of its own. Whee! (I'm actually kind of serious about this -- there are lots of advantages to keeping your daily environment inside a virtual machine, as Smalltalkers know. But I don't want to live in a Smalltalk-only environment.) Write a link-time whole-program optimizer for Idel object modules. Create a real debugger for Idel programs. Which is easier, interfacing to something like gdb or starting from scratch? Object files will need a standard place to put source-level debugging info. See Norman Ramsey's work on ldb, etc., for ideas on exploiting our programmability. What are the special debugging requirements of mobile code? Create a profiler. Write an optional dynamic optimizer using it. Make a search engine allowing complex queries expressed in Idel code. (Saving the bandwidth that'd go into sending a bunch of results over the net for you to filter yourself.) Write a new vm interpreter tuned for tiny embedded devices instead of regular desktop computers. Figure out what you can do for client-side web stuff with this -- there's probably something it could do better among the standard stuff like animations, flash, java applets, javascript. Plug into Mozilla? Network-transparent GUI systems like X are good, but don't make it easy to trade off bandwidth vs. processing power. Combine a mobile-code system with a GUI binding to allow those tradeoffs to be made dynamically. (NeWS was something like that, apparently.) Scripting ubiquitous-computing devices. e.g.: http://www.ddj.com/articles/2001/0101/0101j/0101j.htm -- DigitaScript sounds pretty lame compared to what's possible. (Consider running image processing code directly on the camera to automatically decide which clips are worth saving while you leave it unattended, etc. -- though I don't know if they have the power for that sort of thing...) Use it for behaviors in a multiplayer networked game. The advantage is the combination of safety, resource control, and efficiency, and maybe also mobility. Make an email system where messages are active -- they're programs. Include a way for users to set policies on how much mojo a message has to carry to be seen by the user (or even considered by the filter). Also include provision for some sort of gateway to legacy mojoless email, but letting you easily change your id at the gateway once you're found by spammers. Presto, you've eliminated spam. (More precisely, you still see ads, but only ones that are prepared to pay what you consider your time to be worth.) The programmability component in this idea is not really essential, but it allows open-ended negotiation. (First read up on why active email with Safe-Tcl never took off.) This could take off either of two ways (if it does take off): either the active messages or the antispammitude could be the hook to gain acceptance, with the other aspect hitching a ride. Neither could be the real initial hook in bootstrapping to acceptance, though, because both need critical mass to be worthwhile. Need to hitch along with mojonation or opencola or some dedicated antispam service or something, still. A lightweight language-neutral component-programming system that can insulate components from each other in separate address spaces. I need to review how Synthesis links its quajects. Note that we can make marshaling/unmarshaling fast through dynamic code generation, too -- so we have an answer for all the obvious performance problems in distributed components: communication latency (modules that want to talk a lot can migrate to the same server), context-switching time (no kernel trap), marshaling (compiled instead of interpreted). This still leaves the awkwardness problem. Adapt mlisp to run over idel. Figure out a good way to incorporate x86 instructions. Then get Vapour working with it.