Review of the state of the E project from my perspective

People
------

(a) As far as I know, no one is currently actively working on E implementation or major public E-related projects. If I'm wrong, then please make it clear by talking about your progress on e-lang!

(b) MarkM appointed me maintainer. I have been primarily occupied with schoolwork; the miscellaneous nature thereof has tended to discourage me from working on significant projects (or so I excuse myself). I hope that this situation will change after I graduate or after I start my job, which will occur in May and July of this year, respectively; however, I cannot promise where my enthusiasm will lie. Regardless, I will take the time to *review patches* should anyone else provide them. Please do let me know if I've been neglecting such.

Plans
-----

We have several different E implementations. (This is largely my fault.) However, they feel little pressure to converge, and innovations do not tend to be replicated/backported.

Therefore, I feel that what we most need is an E specification and accompanying automated (Updoc) tests. These materials will be composed on <http://wiki.erights.org>.

However, a wiki is editable by many parties. Regarding specification text, I do not see this as a serious problem, as monitoring and reviewing changes is sufficient. The serious problem is in the tests: if the test suite is editable, and the test suite is executed by E implementations being tested, then anyone editing the wiki can cause arbitrary code execution.

Luckily, we have a solution for that; as the secure programming language, it would be pretty silly if we didn't, no? -- We don't. In the current implementation of Updoc in E-on-Java, Updoc tests run in the privileged environment (or can be run confined but have a basically useless environment; I forget which). In E-on-CL, updoc can be run confined, but then such tests cannot test I/O facilities.

This is what I see as needing to be done:

1. Implement confined Updoc in E-on-Java, so that basic (safe env) language functionality can be tested using untrusted tests.

2. Transfer as much of the already-existing tests as can run in this environment, in E-on-Java and E-on-CL, to the ERights wiki, writing accompanying specification text as interest permits.

3. Make sure that all E implementations have a facility for running against this test suite. (There is one prototype implementation which currently does this: my E-on-JavaScript.)

3a. Enable MediaWiki API on the wiki, for robust category access.

3b. Set up a service to pack the wiki tests into a single downloadable archive, so that the wiki does not need to be spidered a lot.

4. Extend the confined Updoc so that it has a *virtualized privileged environment* so that we can test more implementation functionality. For example, <file> access should be virtualized by providing a temporary subdirectory functioning as a virtual root (note, rather than implementing a mock in-memory filesystem, which would not test the real file I/O code). These changes will make E a better capability system as well as supporting testing. Some may require backwards-incompatible interface changes.

5. Finish migrating all tests to the wiki. (However, in order for all implementations to pass all tests, this would include activities such as implementing DeepFrozen in E-on-Java.)

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>