The upcoming 1.6 release of the open source dispersed storage network software will see a number of usability enhancements. Foremost will be a vast simplification of software configuration. The 1.1 release had a number of fairly unintuitive XML configuration files. For the next release, for each package there will be a single configuration file that needs to be edited.

We will have a “three-tiered” configuration system consisting of:

• Tier 1: Central configuration (the "registry") for all things globally relevant or required to be configured centrally. The open source release will provide a consistent set of CLI tools to manipulate the registry. 
• Tier 2: Local administrative configuration. This will be a simple name/value “.conf” file. This file contains only settings that the typical administrator will need to change. It will not contain unstable or new “tweaky” configurations. The rule of thumb will generally be “is there a reason 80% of the user base will want to change this option?” If the answer is no, it will not be configurable in the ".conf" file. Most configuration options will contain defaults that should be sufficient for most people.
• Tier 3: Advanced module configuration. For module-specific configuration that is "new", "unstable", or "tweaky". Also for configuration that requires some structure but is not important enough to write a CLI for. Most of these advanced module configuration files will be XML files, but the exact format will be module specific. Most new options will be initially introduced in advanced module configurations.
  

All options in the first two tiers are expected to be fully documented before releases. We will want to be especially careful to avoid making backwards-incompatible changes in them between releases, especially in the first tier.

The third tier will likely not be fully documented and any changes may be incompatible between releases. If you don’t provide advanced configuration options there will be defaults compiled into the binaries that will be used. If you do provide advanced configuration files you, as a user, will be responsible for making sure that change them appropriately during an upgrade as there will likely be required values that you have to add or old unsupported values that you will have to remove.

Note that some modules will have their own internal “state”, which is different from the three configuration tiers mentioned above. For example, the slice storage module contains a database that keeps track of mount points and the slice servers and vaults stored on them. The administrator will manipulate this database when he or she adds mount points to the slice server, but the main point of the database is to keep track of the internal state of the slice storage module. Events like vault creation and deletion and slice I/O will cause database modifications. Upgrades to this database occur when upgrading to a new module (for the next few releases this will probably be a manual process).