Originally featured in the most recent TC Channel, here is TopCoder project manager Michael Fogleman's review of recent updates to the most widely used component in the catalog - the configuration component.

Today we will discuss two high-visibility components in the TopCoder catalog. They are the Configuration API and the Configuration Persistence components, which were both only recently introduced to replace the traditional Configuration Manager and refine TopCoder's approach to configuration management. Today's discussion will hopefully be useful to any members looking to get started in Component Design or Development, or even in application Assembly challenges.

Historically, the Configuration Manager has been used by 65% of the components in the catalog. This number reflects just how important it is for each component designer or developer to be completely familiar with these two components.

What's New
The new Configuration API and Configuration Persistence components were recently added to the catalog to correct a few technical shortcomings in the previous Configuration Manager component. These include:

1. Decoupled Persistence Logic
   The new components decouple configuration entities from the logic which saves or loads the configuration. As a result, configuration can be managed independently from however it is persisted or obtained.
2. Programmatic API
   The new components allow configuration objects to be programmatically created and modified. This makes it possible to use components without creating a configuration file at all.
3. Simplified Integration
   The new components simplify the passing of configuration from component to component. In this new paradigm, components will typically accept a configuration object in their constructor, instead of a string representing a configuration namespace.
4. Advanced Functionality
   The new components also support operations based on regular expression matching and generic processing over the nodes in a subset of the tree.

The Configuration API component is a simple container for storing configurations. Its functionality includes:

1. Name → Value mapping for configuration values
2. Name → Value mapping for child configuration object nodes
3. A synchronized wrapper
4. A default implementation of the configuration object interface

This container can be used in a stand-alone manner, creating and manipulating configuration programmatically. Or the Configuration Persistence component can be used to load or save configuration objects from or to files. The default implementation is backward-compatible with the file types and formats used in the Configuration Manager component.

Let's take a look at a quick example to see the expected usage patterns for these two components.

Let's say an application is made up of two components and some assembly code. One of the two components also depends on a third component to accomplish one of its tasks. The expected usage pattern can be summed up as follows:

1. The three components only depend on the Configuration API component. Only the assembly code uses the Configuration Persistence component to load the configuration and pass the configuration objects to its two child components.

2. The configuration file -- and thus, the configuration objects -- will only hold the configuration for components A and B. Any configuration needed by C will be programmatically created by B. B's configuration should include any parameters needed to fulfill this role. This decouples the parent of B -- the assembly code -- from C, a component that is only indirectly depended upon

As an alternative to #2, the configuration object for B could have a nested configuration object for C that B could then pass on directly instead of programmatically creating a new one. The parent of B is no longer decoupled from C, from a configuration perspective, but this may be a better option when the amount of configuration for the indirectly associated components becomes large and unmanageable.

If you would like to see these components in action, check out the File Delivery component, which was designed for the finals at this year's TCO.

The Configuration API and Configuration Persistence components will soon become more and more mainstream as new projects begin to adopt them and phase out the existing Configuration Manager. They aren't too complicated to use, but you will need to be familiar with them to get an edge on your competition. Good luck!

Related links:

• This week's current Component Design Challenges
• This week's current Component Development Challenges
• Using the .NET Configuration Manager
• Component Tutorials