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

[Marcus Brinkmann]

At Sun, 14 Jan 2007 07:21:38 -0500,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Fri, 2007-01-12 at 20:23 +0100, Marcus Brinkmann wrote:
> > This is an example were "transparent access" to the storage not just
> > means inspectability, but intimate knowledge about its structure.  If
> > you want to leverage the flexibility illustrated by the above
> > examples.  the algorithms to make use of this must be standardized and
> > exist outside of the bundle itself.
> 
> > If that is a goal, then it seems not to make much sense to have the
> > algorithms twice, once in the bundle and once outside.
> 
> This is complete nonsense. The algorithm for strlen() is well known. It
> still makes sense to have it in a common place: libc.
> 
> In the same way, the constructor algorithm is well known and can be
> reproduced by anyone.
> 
> In the presence of translucency, there is still an argument for a
> constructor: things that run in separate processes are less
> failure-prone than things that run in libraries.
> 
> The great weakness of libraries is that they share address spaces with
> their host application. This makes each vulnerable to flaws in the
> other. Purely from an engineering perspective, it is sensible to make
> the functionality of each process as small as it can be made while still
> achieving acceptable performance.
> 
> Libraries are a tool that you should only reach for when the performance
> cost of engineerability becomes prohibitive.

You are conflating separate issues.  If you want address space
separation, then there is no reason why the C library can not spawn
arbitrary helper processes to execute the algorithms desired by the
user.  I leave open the question for now if this makes sense in this
case or not.

Either way it still makes sense to only pass around directories, not
full blown constructors.

Thanks,
Marcus