next up previous contents
Next: Future Improvements Up: The Basic Services Previous: The HDM Event Model

The HsConfigService

  One of the most important design concerns for Haystack is the customizability of the system for the preferences of a given user. It is important to provide a single point of entry for configuration of a wide variety of services. To this end, Haystack includes a configuration service, HsConfigService. A baseline implementation of the HsConfigService is disucussed below, as well as possible improvements for added flexibility and scaleability.

Currently, Haystack defines the following format for configuration files:

Keyi Val1 Val2 Val3 ... Valn

This format is very simplistic, and does not allow for repetition of keys. Each key®value(s) mapping must reside on a seperate line. Values are assumed to be seperated by single spaces. Examples of keys are: HAYLOFT (the location of the user's Haystack repository), ObjectStore (the file used by the persistent object store), and CacheDirectory (the directory in which to maintain cached information). Lines that start with the `#' character are comments and are ignored.

HsConfigService currently provides only two interesting interfaces: getVal(n) and getVal(n,i). The first returns the Vector of values corresponding to the key n. The second returns the string corresponding to the ith value for key n. Both return exceptions if the key is not found (see Appendix gif).

The only other functional part of HsConfigService is the initialization routine which ensures that the user's Hayloft directory exists. If not, HsConfigService will create it, and check for read/write permissions.





Copyright 1998, Eytan Adar (eytan@alum.mit.edu)