component dependencies (Was: union mounts)

I've split this out into a separate discussion, because I think it's
getting away from the mechanism of union mounts and into the
foundations behind component dependencies.

> Seems to me one would want to fully exploit the opportunities
> provided by interacting local namespaces and union directories
> before importing legacy concepts from architecturally (-backward?)
> -less-flexible systems. Focussing strictly on 'what does union dirs
> buy me' ignores that unions (and applications, for that matter)
> interoperate with the rest of the system in a coherent fashion.

Agreed. However, I assure you that it is the interactions of local
namespaces and union directories by themselves which I'm denouncing. I
don't like the UNIX-inspired use of filename space. It allows add-hoc
conventions to be built into a untyped space (the pathname space). It
confuses logical and physical namespaces. It allows top-down
dependencies to be encoded in conventions instead of explicit
dependencies (I apologize if that was confusing, I'll explain
more). It is the single largest reason (IMO) that today's system are
each 'custom' built. From what I've heard so far, I still maintain
that union mounts are another step in that direction, and that's not a
direction I want to go.

I want to be able to separate configuration data from application
data. Or perhaps more generally, mutable application data from
non-mutable application data. I would like to move this configuration
data and external dependency data external to the applications
themselves so it can be managed in a uniform manner. I don't want
applications storing information about the physical world in their own
custom configuration mechanism.

Union mounts approach a solution to this problem, relative to the
traditional UNIX model. In a union mount system, one could be sure to
make all applications hard-code all 'logical paths'. These paths would
exist in the local pathname space, and the union mount system would be
the external configuration mechanism by which external physical
entities are bound to local logical requirements. However, there is at
least one major problem with this. Logical path requirements of an
application are not published.

This is the only important point of this email:

** The only way to figure out what paths in the local space an
** application may access is to run the application and watch.

This is true of both traditional UNIX and union-mount Plan9 style
systems.

I propose that it's a better solution to explicitly publish all static
dependencies of an appliction. If an application requires a version of
TCL, I would prefer it publish this explicitly to the OS so the
configuration system can be aware of it and bind to that requirement
explicitly.

In analogy form:

1) The UNIX fixed-pathname space makes every system a construction
site of raw materials. First a foundation is formed, and then a
building is built on top. However, very little is sent to the site
pre-fabricated. Instead, raw materials and plans are delivered. Every
building is a little bit different, and each layer is dependent on the
last.

2) The Plan9 method allows you to create many buildings. Each building
is smaller and more specialized than the UNIX building. However, each
building is still construted from raw materials, and each layer must
be custom fitted on top of the last.

3) The method I'm proposing is to pre-fabricate parts and ship them to
the construction site. To assemble the building, all the 'glue' pieces
must be constructed on site. The glue pieces could be measured,
documented and reused in connections between those prefab parts in
another building.

Opensource UNIX is the prime example for my UNIX description, but
commercial unicies and applications exhibit this kind of behavior as
well with their custom configuration files and often hardcoded install
locations.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net