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

[Jonathan S. Shapiro]

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.

shap