|
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.
|
