Introduction of a Site Default Layer


Programs locate resources by resolving them in some namespace. In traditional systems, the root of this namespace is controlled by the system administrator. Lazy programs check only a system configuration directory for their parameters. Thorough programs examine two or three paths for configuration information, with at least one mechanism under user control (~/.programrc or an environment variable $PROGRAM_CONFIG).


This situation often leaves users in an awkward position, unable to change a configuration that
shouldn't require a system administrator's attention.

Snowflake addresses this issue by declaring no distinguished node of a namespace. Users are free to pass programs a new namespace instance. When the program resolves a path in the user­supplied namespace, the user has the opportunity to provide any configuration data desired.

Of course, system administrators would still provide default name trees. The key element is that users have ultimate control over the name­to­resource mapping that programs use on their behalf.

Where do configuration files go? In a traditional system, if they go in the sysadmin's space, the user is unable to change a program's configuration. If they go in the user's space, there is no straightforward way to distribute and update site defaults. If they can go in either place, we demand every program to provide such a mechanism. Some won't.

Snowflake defines a "site default" layer, where system administrators supply reasonable site defaults. Because users can override any name binding, these configurations don't hamper users. And since programs need look in only one place for configuration information, they are simpler and more consistent.

Configurable Component Organization


Because software components employ user-supplied namespaces exclusively to locate resources, we avoid the need for process-relative names. In traditional systems, programs are written with careful attention to how they fit into process granularity. Once a program leaves the programmer's hands, its orginization is fixed, because each process-sized unit requires and carefully shares the resources of a single process.

Snowflake software can be
written without regard to how objects pack into processes. Because components don't acquire resources from the process object but from a user-supplied namespace, multiple components can be colocated into one protected process context, or individual components may be separated across contexts or across machines. The organization of components in contexts can be assigned at runtime according to the user's safety and performance requirements.

Traditional programs "plug in" to the process construct to acquire resources. Two such programs could not coexist in a single traditional process.

Snowflake components acquire resources via their own user-supplied namespaces, and can happily coexist in a single protection domain.