1 Sep 2005 22:45
Re: Draft of Joe-E, a Capability-security subset of Java
On 8/31/05, David Wagner <daw@...> wrote: > John Carlson <john.carlson3@...> writes: > >How will you give authority to a Joe-E > >program? What can a Joe-E program do without > >access to native libraries? > > Those are parts we'll work on soon; they are intimately tied in with > taming, and taming is next on our plate for later this fall. (The answer > to the second question is "compute side-effect-free functions" -- but > our next step will be to work on taming the Java standard libraries, > so that Joe-E programs can do more, including I/O.) But we wanted to > try to start nailing down the language first. A slightly different question has a much more satisfying answer: "What can a program do with Joe-E code?". Answer: "Vastly reduce the per-application code review work." For example, most of the Java applications I write are written to the Waterken Server. The architecture of this server has the feature that the server links to the application code, not the other way around. (Some fancy introspection code in the server makes this work) This design results in application code that is just plain Java code, with no links to _any_ standard libraries. Each new application means writing more of this plain Java code and reusing the existing server application. I am hopeful that the Joe-E project will produce a verifier that I can run on this application-level plain Java code to automate parts of the code review process and, more importantly, put some teeth into the assumptions that are made about the flow of authority within a capability-based design.(Continue reading)
On Fri, 2 Sep 2005, Kevin
Reid wrote:
> On Sep 2, 2005, at 8:10, Mark Miller wrote:
> > Kevin Reid wrote:
> >> I haven't thought of a decent name for Guard, though; just
> >> ExtendedGuard, SugaredGuard, FancyGuard, etc., which might be true but
>
> However, I think it will eventually be important to preserve the
> guard's ability to override those operations to be more than that; for
> example, the guard resulting from this expression can be much more
> efficient if IsAny (previously discussed for replacing the ==-pattern)
> can implement | to define a new IsAny guard instead of an or-guard:
>
> accum none for item :notNull in dataSource { _ | IsAny[item] }
This looks completely unfamiliar to me. Can you explain?
> Hypothesis: eventually, we will want the ability to write "if (g =~ eg
> :ExtendedGuard) { eg } else { __extendGuard(g) }". Thus a guard can
> offer optimized/customized versions of the guard compositions (in which
> I include not/0), or its client can add the default extensions when
> necessary.
RSS Feed