[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:27:25 +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:21:53 -0500,
Jonathan S. Shapiro wrote:
>
> 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.
This thread could be about that. But it wasn't when it started and
the shift was far from clear.
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, (continued)
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- constructor daemon vs. constructor library, Neal H. Walfield, 2007/01/15
- Re: constructor daemon vs. constructor library, Jonathan S. Shapiro, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Neal H. Walfield, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Neal H. Walfield, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons,
Neal H. Walfield <=
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Pierre THIERRY, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- Capability simulation, Jonathan S. Shapiro, 2007/01/11
- Handing off... (was: Re: Translucent storage: design, pros, and cons), olafBuddenhagen, 2007/01/12
- Layering in EROS/Coyotos, Jonathan S. Shapiro, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/11
- kernel (was: Re: Translucent storage: design, pros, and cons), olafBuddenhagen, 2007/01/11
Re: Translucent storage: design, pros, and cons, Anton Tagunov, 2007/01/10