[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Potential use case for opaque space bank: domain factored network st

From: Jonathan S. Shapiro
Subject: Re: Potential use case for opaque space bank: domain factored network stack
Date: Mon, 08 Jan 2007 10:10:40 -0500

On Mon, 2007-01-08 at 15:31 +0100, Tom Bachmann wrote:
> Hash: SHA1
> Jonathan S. Shapiro schrieb:
> > Second, Jonathan has no objection to having a constructor that
> > implements methods
> > 
> >   createYield()
> >   createTranslucentYield()
> > 
> > with the difference being that the second returns a process capability
> > to the invoker. Holding the process capability is sufficient (with a bit
> > of helper code that does not need to know anything about the subject
> > application) to ensure transitive translucency.
> But, if we, as free software enthusiasts, think that any use of
> createYield (that is, starting a program you are not allowed to look at)
> is bad, why should we include that operation into the interface at all?

You should not. I was not stating what you should do. I was stating what
my actual position is.

I do think that you are making a mistake, and I will try to generate
examples later today or tomorrow.

> And then, why is it unreasonable to consider a different design that
> achives the same goal (starting processes, with transparent memory) in a
> different and (potentially, at least) easier, simpler to understand way?

It isn't, though I still maintain that the implications of your
preferred design cannot yet be understood, because there is not yet a
comprehensive design. Whatever you do, I urge you to design it and try
to understand it before you build it, and to test the design by
considering difficult cases (in the sense of "cases with unusual
security requirements") before building it.

Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100

reply via email to

[Prev in Thread] Current Thread [Next in Thread]