Software program configuration
Context always requires some contemplation...

Context: optional and occasionally supremely useful

The Context Feature

Context is everything

You may have heard it said that "context is everything" and soon you may realize how central that theme is to the raw power in the ZaphodsMap system.

Context can be set for each software product, independently, and does not have to be unique. If you own two computers, you can set the context to be the same on both, but you do not have to.

Power for the Busy Tech Worker

If you are responsible for configuring software, it definitely worth learning about the context feature because, after some difficult contemplation and planning, you will be able to simplify installation scenarios. How? Details below...

Contemplating Context

Context as Machine ID

It can be helpful to think of the default context as a flexible form of machine identification. Because the administrator assigns the default context, several machines can have the same default context. If you had a group of machines which are supposed to provide round-robin backup for each another, it would be a good idea to give all machines in the group the same default context, and then all the production machines would pick up the same settings, while being distinguishable from other development and staging computers.


The simplest strategy is not to use context at all. This is perfectly fine if you are taking care of one (1) computer, or if all computers are supposed to have exactly the same settings.

The next strategy is to give every computer its own unique name, and to set up configuration values essentially on a per-computer basis. This lets you have one master set of configuration files which are identical across all computers, except for ZMGlobal.xml which states the computer's unique name. The only drawback is that you will have up to N duplicate entries in your configuration file, where N is the number of computers involved.

The third strategy is to invent names for groups of computers wherein which all software should behave the same. A typical scenario would involve a cluster of computers which all run a software package sharing the same settings, regardless of whether other details such as computer name, ip#, or hardware details are identical. You would give each computer within a group the same context setting.

A final strategy is combine any of the above plus extra ZMContext.xml files placed in the software's folder, in order to override a single aspect of the software. The plausibility of this depends on the flexibility of the software in question.

Implementing Context

Implementing context is easy compared to thinking about it!

Global Context

The default so-called global context is set once per computer in the central ZMGlobal.xml file. This file is always located in the ZaphodMap Root Folder, i.e. whatever is defined by the ZaphodsMap environment variable.

The context is blank by default.

download sample ZMGlobal.xml

Branch Context

You can override the global context for any software branch by placing a ZMContext.xml file into the branch folder.

Local Context

You can override both global and/or branch context by placing a ZMContext.xml file into any folder containing a ZMKeybox.xml file, or any folder containing a software program which itself uses ZaphodsMap.

download sample ZMContext.xml (save-as ZMContext.xml)

Creative Commons License This web site content is licensed under a Creative Commons Attribution 2.5 License. The ZaphodsMap web site is published by HREF Tools Corp. If you use ZaphodsMap, please mention at least once in your software source and at least once in your software documentation. All other trademarks are the property of their respective owners.