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. _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
