E 语言：分布式对象、能力权限与开放源码

Electric Communities 开发联网虚拟世界时，需要让处在不同机器上的对象协作。网络会有延迟，机器会失效，参与者也未必互相信任。若程序只沿用本机顺序调用的直觉，一个远端操作可能拖住后续工作；若把所有组成部分都交给同样宽泛的权限，合作对象又可能破坏彼此的数据。

项目保存的历史说明，把 Joule 列为重要前身，并将早期 Java 扩展称为 Original-E。参与这一阶段的有 Doug Barnes、Chip Morningstar、Dan Bornstein、Gordie Freedman、Eric Messick 等人。团队使用它建设 EC-Habitats，并进行了测试部署，经验随后进入新的 E 设计。

参考：[2] [3]

页载1996年6月更新日期的早期教程，已经说明如何从 Electric Communities 网站下载 E 扩展，以及如何理解通道、分发器、消息发送和等待值的语句。它展示的是 Java 扩展阶段的词汇和用法，不能直接当作后来 E 语法的说明书。

后续设计包括 Mark Miller、Bill Frantz、Jamie Fenton、Morningstar、Doug Crockford、Bornstein 等人的工作。项目历史把这一阶段与 Original-E 分列，并说明新的设计吸收了早期部署的教训。因此，E 的形成是一连串实现与重做，不能把所有版本压在同一个假定的诞生日上。

Miller、Dean Tribble 与 Jonathan Shapiro 在2005年发表的技术论文明确记载，Electric Communities 于1998年开放 E 的源代码，之后项目在 ERights.org 的社群中继续发展。这里把1998年作为可核实的开放源码阶段；1996年的手册则说明它此前已有另一种实现形态。

参考：[1] [2] [3]

2005年的论文用一个保存状态的 statusHolder 对象解释 E 的方法。账户管理程序更新余额，电子表格和财务程序订阅变化。若保存状态的对象在更新过程中立即调用每一个订阅者，订阅者又可能出错、重新订阅，甚至触发下一次更新，让尚未完成的操作相互干扰。

E 保留立即调用，也提供用左箭头表示的 eventual-send。论文把通知改为先安排稍后投递，更新者继续完成当前这一轮工作，订阅者的反应随后再处理。这个改变不是忽略结果，而是把何时执行另一项工作变成语言模型中可以明确讨论的选择。

对象、执行栈与待投递队列共同构成 vat。每轮消息处理先完成，才取下一项；不同 vat 可以并发，并可处在不同机器上。这个模型减少了一类交错情况，但程序仍须处理网络失败和无法继续推进的情况。

参考：[3]

通知顺序解决不了全部问题。如果电子表格和账户管理者拿到的是同一个既可读取、又可修改状态的对象，订阅者仍可能调用修改操作，发布一个假余额。论文于是把接口分成两个对象：一个允许读取和订阅，另一个允许修改。

账户管理者保留修改对象，只把读取对象交给订阅者。获得哪个对象引用，就关系到能够进行哪些动作；合作不必同时授予所有权限。这体现了 E 使用的最小权限原则，也把访问控制与并发控制放进同一个程序例子。

论文同时保留了模型的边界：同一 vat 内某个对象若无限循环，其他对象也可能失去进展。限制修改权限可以保护数据的一致性，却不自动解决所有拒绝服务问题。

参考：[3]

到2005年，作者报告已有企业和大学用 E 教学、快速制作分布式原型及开发系统，但仍不把当时的实现视为适合生产使用。论文称其为以 Java 编写、速度较慢的解释器，并提到基于 Common Lisp 和 Squeak 的实现工作正在进行。

这些后续尝试表明，E 的贡献不仅在一套语法，也在于把异步消息、对象引用所代表的权限，以及不完全信任条件下的合作放在一起研究。1998年的开放源码让这种设计进入社群接力；后来的解释器、库和其他语言上的实现，则应按各自阶段另行叙述。

参考：[2] [3]