Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons

[Jonathan S. Shapiro]

On Mon, 2007-01-15 at 20:16 +0100, Neal H. Walfield wrote:
> At Mon, 15 Jan 2007 14:10:26 -0500,
> Jonathan S. Shapiro wrote:
> > 
> > On Mon, 2007-01-15 at 18:48 +0100, Neal H. Walfield wrote:
> > > > (1) is infeasible in a system where the instantiating party does not
> > > > have access to the capabilities that the program will require. One
> > > > purpose of the constructor mechanism is to allow (e.g.) an instantiated
> > > > password agent to have access to the password database when I do not.
> > > 
> > > ... and likely should not have.  Yet, if the yield is running our of
> > > client provided transparent storage, the client effectively has access
> > > to the database.  So, don't you want these types of services to run as
> > > daemons?
> > 
> > Absolutely not. I want to be able to safely polyinstantiate them, which
> > is why I need client-provided storage to be opaque.
> 
> But we are not talking about Coyotos; this thread is about HurdNG and
> you contended that HurdNG should retain constructors.  As such, you
> must argue within that framework.

No. This is a discussion of whether the HurdNG design is desirable. As
such, it is "fair game" for me to identify things I want to do that
HurdNG precludes.

There are good reasons to want to be able to instantiate sealed boxes
that handle passwords, crypto keys, and so forth. In some cases there
are compelling reasons why I should be able to instantiate one using
storage and schedule resource that I provide over data that I cannot
access. One reason is for scheduling compatibility. Another is for
concurrency management. A third is for support of collaboration under
mutual suspicion. HurdNG does not appear to address any of these cases.
It is not a good design if these cases must be satisfied from
system-wide storage, and it is not a good design if I must use a
system-provided daemon that does not (and intrinsically *cannot*)
operate under the scheduling discipline of my system.

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