[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 18:48:06 +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 12:36:47 -0500,
Jonathan S. Shapiro wrote:
> On Mon, 2007-01-15 at 18:33 +0100, Marcus Brinkmann wrote:
> > So let's separate the issues.  There are two issues:
> > 
> > 1) Should a linking (interpreter selection etc) algorithm be provided
> >    along with the program files or should it exist in the ambient
> >    space of the operating system?
> > 
> > 2) Should the algorithm be run in its own address space or not?
> (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

reply via email to

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