[e-lang] robust capability language?
erights at gmail.com
Mon Mar 5 15:23:37 CST 2007
On 3/5/07, Bryan Rasmussen wrote:
> What, currently, would be the most robust capability language out
> there, or the most robust/scalable capability based application.
The collected list of objcap language projects past, present, and in
development is at
<http://wiki.erights.org/wiki/Object-capability_languages>. If anyone
knows of languages which should be listed there, please add them.
After all, it's a wiki.
Of these, currently, the only ones I would attempt to build something
else on are Joe-E (and Joe-E+Waterken) and E.
> I suppose Waterken server will probably turn out to be the forerunner
> in capability based systems but I think it, being a webserver, is not
> a good fulfillment of the implicit promise of capability based
> security (if one is explaining capability to a CEO in the fable
> elevator talk the thing that would first jump to mind is the ability
> to run programs from the net on a client machine with access to
> limited resources of that machine and not be hacked to pieces in a
The full Joe-E+Waterken system is indeed a web server. However, the
underlying pieces are more general than that -- they can be composed
in other ways. Joe-E enforces that your Java code is in the sequential
objcap subset of Java. Tyler's just-announced ref_send library adds to
this a library (written in Joe-E) for doing eventual sends / promises
/ communicating event loops. Neither of these is specific to web
service. Tyler's ref_send library allows the event loop to be provided
by an existing event loop framework like SWT or AWT.
In order to use Joe-E + ref_send to run applications on the client,
the main thing that's missing is a set of Joe-E taming decisions for
AWT and/or SWT. From our experience with E, one should expect this
taming effort to be substantial, and the place where you're most
likely to make a fatal mistake. To vet these taming decisions, one
should also try to modify the sources to 1) remove all code which
should be unreachable from the tamed API, 2) modify the remainder so
that as much as possible of it passes the Joe-E verifier, and 3) only
make mods that you believe to be compatible with the tamed original.
Also, the boundary between "web server" and "client" is muddier than
it appears. Our current Scoopfs work at HP uses a waterken server
process for each user, running on that user's machine. Each user uses
their web browser as their local UI for interacting with their local
web server. Between machines, these web servers talk to each other
peer-to-peer. For Scoopfs, all browser-to-server communication occurs
only within each machine.
Text by me above is hereby placed in the public domain
More information about the e-lang