[E-Lang] Announcing stl-E 0.8.9k: An interim non-distributed release

[Marc Stiegler]

Since the following point is buried in the middle of markm's message
announcing the new version of E, I shall pull it out and highlight it for
everyone who might have either missed the note or missed the ramifications:

> This is the first version of E supporting locally untrusted code (!!!)

In case anyone missed this, it is worth noting that 2 weeks ago markm and I
thought the ability to locally run untrusted code was at least a year away.
A breakthrough or two later, and it was a weekend's effort, and this version
bears the fruit.

It is my belief (correct me if I am wrong, markm) that with this release of
E, it is now possible to distribute full-power applications (true caplets)
that are capability secure. For example, the following tiny E program is a
launcher able to bring to life Emaker caplets with all the power of standard
desktop office apps like Word, Excel, PowerPoint, and Access, yet bound
within the confines of the authorities they need:

#Crude but effective Desktop Caplet Launcher
#On command line, arg1=emakerFilename, arg2=documentPath
def signalAppFinished() {interp continueAtTop}
def appMaker := <import: (interp getArgs[0])>
def doc := <file: (interp getArgs[1])>
appMaker new(doc, signalAppFinished,
<import:java.awt.*>,<import:java.swing.*>)
interp blockAtTop

This launcher starts the app with these authorities:
     --write to the screen, read from mouse and keyboard
    --read and write the single document which the user wants the app to
edit
    --inform the launcher it is done (is this really an authority? Probably
not :-)

This is a ridiculously tiny set of authorities. Yet these are exactly the
authorites that common office apps need. Pick thousands of caplets of the
net, seek out caplets written by known crackers, ask the developer of
BackOrifice to whip up a custom caplet just for you, and run them in safety.

Now all we need are some desktop caplets to launch with this launcher :-)

--marcs

PS: I used the phrase "all the power" a bit loosely here. There are some
functions that cross sessions (preferences files) and applications (cut and
paste across apps) which are not supported by the simple model of computing
allowed by this launcher. I know how to support these--I've thought about
this problem a great deal--but it takes a larger framework to support
full-flexible full-power caplets.

PPS: For those of you who actually want to try this launcher out, the
imports of swing and awt probably have to be handled slightly differently. I
will go into the real grit on this (with markm's assistance, since there are
aspects of how these imports work I don't fully understand yet) with anyone
who seriously wants to write such a launcher/caplet combo.