E Priorities & Triage
Mark S. Miller
Sun, 18 Apr 1999 14:23:10 -0700
We're on the edge of releasing E 0.8.2, and when we do my announcement email
will list what's new there. But the big news of this upcoming release is
that there is no big news, even though it took more work than many earlier
releases. For the kind of thing E 0.8.x has been trying to be, we're
starting to approach "feature complete". The work in this upcoming release
was mostly on improving the coherence and correctness of the features we've
In this message, I'd like to bring up a more important question. Soon we'll
be declaring E ready for publicity and promotion, announcing it on slashdot
and such. I will also be needing to find support for E -- be it a VC funded
startup, non-profit donations, more contracting, a research lab job, or
something else -- so I can continue doing this full time. Hopefully the
nature of the support will enable me to ask some of you to join me full time
So the question is, what remaining work should be done on E before we can
declare it that-kind-of-ready? The most important criteria is that those
who decide to download and play will quickly have a rewarding experience, so
we can suck them in. Also, is there anything about the current system
that's just embarrassingly bad?
Here are my candidates of major items still to be done in this phase:
More book chapters. Specifically
The blankness of so many javadoc pages communicates
Many of our early adopters are here, especially when we
announce on slashdot. We've gotta have a clean install.
Continual bug fixing as it comes up, of course.
Vat creation and manipulation API.
The only way to get true concurrency in E is to create more
Vats. However, we have not defined an API by which E code
in one Vat creates and starts another Vat, and how that
code manipulates the Vat it started. I imagine something
like how one KeyKOS Domain / EROS Process creates and
Rather than take a shortcut, for now I'm simply gonna have
all inter-Vat E messaging go through the full Pluribus
comm system, even when they're in the same JVM. Given this,
we've already got most of the mechanism, we've just gotta
define and implement an API around it.
Without this, our concurrency story is obviously
incomplete, but I'd love to hear arguments that we can
postpone it anyway.
It's the only reasonable way to ensure the examples in the
book are accurate.
A small number of small example smart contracts.
Like, what's all this stuff for anyway?
Here are my candidates for painfully important items that can wait till
after this phase:
Can't actually *do* any smart contracting without it
Vat Location Service
Once we have persistence again, we have to revive this.
There's also been a lot of good thinking about the firewall
issue, some of which will need to be implemented soon.
Fortunately, I saved all my notes from that meeting at
Bill's house. I even know where they are after moving!
Auditors, (see http://www.erights.org/elang/same-ref.html )
the first step to
All of which are next on the list once we have auditors.
Back in OriginalE days, Danfuzz went through the Java
standard libraries and determined what subset of them obey
capability discipline. I need to parameterize my E-to-Java
binding mechanism with this information, so E code only
sees this subset of Java.
We can't support mutual suspicion within an address space
until we do this. The new simplified & more powerful smart
contracting story (The Game Creation Game) requires this.
Now that more of E's implementation is moving from Java
into E (as Danfuzz long ago recommended), the performance
penalty for interpreting parse trees rather than compiling
is starting to hurt. The available of the GNU Java-to-C
system gives hope that E may run as fast as symbolic
languages normally do, while still allowing us to build
on the Java libraries. (The interpreter would remain an
executable specification in pure java.)
All of us have lived through dealing with languages that
don't yet have one. 'nuff said.
Reasonable error diagnostics, especially in parsing.
AFAIK, I always throw exceptions exactly when I should.
However, which exception I throw for what, and how informative
they are, needs an large overhaul.
What did I forget? What's on the wrong list? What should be added or
removed? What needs more explanation?
Most important: What would make a difference in your choice about using the
Opinions solicited. Thanks.