[cap-talk] T.120-like apps -> Joe-E
Jed at Webstart
donnelley1 at webstart.com
Mon Apr 25 15:12:37 EDT 2005
At 10:39 AM 4/25/2005, David Wagner wrote:
> >Joe-E is the 100% pure Java subset that is capability secure. It uses
> >the Elib for communication. A big part that is not yet complete is the
> >verifier that will confirm that a class does not use any authorities it
> >does not receive as explicit messages, i.e., the verifier will verify
> >that a class follows the rules laid by in E by the safej files (which
> >specify which methods are suppressed, and which classes are considered
> >unsafe, for capability discipline). Of course, static class mutables are
> >also rejected by the verifier, as another example of verifier behavior.
> >Joe-E programs will have approximately all the promise-pipelined
> >object-capability properties of E [...]
> >Anyway, David Wagner has a small project planned to carry that work to
>Right. For the onlookers, a warning: Joe-E doesn't exist yet, and
>I don't have anything to talk about just yet. Sorry for the vaporware.
>A little more background, for the curious. My big goal is to define
>a subset of Java that is well-suited for capability programming.
>Our first task will be to identify a safe and reasonable subset of Java
>(this is not totally trivial), and implement a verifier to reject code
>that steps outside this subset. The next task is to safely make some
>class libraries available to such code. This could take some time.
>To let people know where we're going, we're focused mainly on standalone
>systems right now. We may leave the distributed systems / cross-host
>communication stuff (e.g., promises), as well as the integration with
>E (e.g., Elib) to someone else, or at the very least, to a later day.
>You've got to start somewhere, and it's going to be a big task just to
>get to something that works well on a single host.
Within a single host or within a single language environment? Is the
OS environment relevant to these considerations? If so can you elaborate
on the OS considerations?
If capability communication works between, say, Unix processes
(that's what their called in Unix - we call them "active objects" on this
list/in this community ;-) then it seems to me it would extend naturally
to a network. If they are language specific, then I'd be interested to
hear the cross language issues. Are any cross language communication
of capabilities possible?
I wonder if, when extending beyond the language or OS (see above) it
might be possible to skip directly to something like YURLs for
capabilities? Perhaps something along the lines of the DCCS might
be needed to map internal to external capabilities, but at least if
it was done in such a way it could be done once and become available
at the highest possible level. It also seems to me doing so might
simplify things a bit. It would allow us to have to truly have one
standard "capability" function all the way up and down the levels
of implementation from the innermost language supported level
to the network level. All *very* blue sky mind you.
>We hope to have a spec for the language subset available to pass around
>sometime in the next few months, and we'd very much welcome comments at
>that time (or advice before then).
Well ... as I've often said, if you don't at least plan for the network
case and use "network discipline" then I believe you are likely to
overuse the flexibility available in the local environment and put together
a system that will not extend and will therefore die. I believe this
strongly based on multiple past experiences. Pretty general I
know, but you did ask.
More information about the cap-talk