[Top][All Lists]

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

Re: Program instantiation (was: Re: Translucent storage: design, pros, a

From: Neal H. Walfield
Subject: Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons
Date: Mon, 15 Jan 2007 20:16:58 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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.

reply via email to

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