As the HsConfigService is currently implemented in the most simplistic functional model possible, some future improvements are discussed below. The first major improvement would be in the format of the configuration file. This file should allow for added robustness (in terms of allowed keys and values). Ideally, services in Haystack should be able to construct a set of rules for configuration items they will require. This rule could then be passed to the HsConfigService and it, in turn, would confirm that the key/value mappings it has loaded from disk adhere to the restrictions of the rules.
An example rule would be (as proposed by the HsPersistentObjectService to the HsConfigService): ``Make sure the ObjectStore key exists, and has one textual value.'' Another example may be: ``make sure that key foo can be read as an integer, and that it has one of the following values: 1,5,7.'' Once Haystack has a wide variety of services, the exact scope of the rules will become evident. It should then be possible to formulate a rule language for services.
Finally, a user interface that allows for changes and explains the properties of different keys would also be invaluable.