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.
The Configuration API component is a simple container for storing configurations. Its functionality includes:
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!