The following common terms have a specific meaning within the context of the NodeBrain Kit and Caboodle Framework.

caboodle	A directory containing a collection of components organized into a predefined set of subdirectories. Components make reference to other components using paths relative to the caboodle root directory. This makes a caboodle portable.
kit	A collection of components organized like a caboodle, but intended for distribution and used to construct caboodles or add functionality to existing caboodles. A caboodle may be composed from multiple kits.
agent	A NodeBrain script that runs as a background process, or daemon.
plan	An XML document used to represent a set of NodeBrain rules or configuration files based on a translation scheme. A plan compiler converts a plan from XML document format into a target format, often NodeBrain rules.
adapter	A script or program that adapts a caboodle component to another application or specifc environment. For example, adapters may be used to send alarms to syslog, email to administrators, and SNMP traps to downstream systems.
servant	A script or program that runs as a child to NodeBrain to perform a function for which another programming language is preferred. Servants may communicate with NodeBrain on stdin, stdout, and stderr.

The Caboodle NodeBrain Kit does not make use of all the directories listed below. Some are defined only to provide guidance for other kits.

.nb	A special directory for use by the nb (NodeBrain interpreter) command. If a caboodle.nb file is found in this directory, NodeBrain sources it at startup. Variables defined here may be used within rule files to adapt to a particular instance of a caboodle for a given application, where other components are shared by all instances. This is the only directory within a caboodle of which the NodeBrain interpreter seems to have some awareness. In fact, the NodeBrain interpreter has no awareness of caboodles. It simply supports a .nb directory in the working directory, and the caboodle concept depends on the caboodle being the working directory when the interpeter and all other components are invoked. This directory should not be used by components other than NodeBrain and node modules to avoid naming conflicts.
adapter	Commands that adapt a NodeBrain application component to specific interface requirements. For example, alarm adapters can be included here to adapt alarms to a particular protocol or to an external event management system interface.
agent	NodeBrain agent scripts. It is best to manage agents using an agent plan, in which case the agent script in this directory will be generated for you by the agent compiler. This directory also has files that identify the expected state of each agent.
bin	Used for commands that do not fall into the categories for which other directories are defined. See adapter, agent, exit, and servant directories.
cache	This directory has subdirectories that contain files used to cache information for a limited duration to avoid more expensive lookup, often where lookup may be relatively frequent. In cases where deleting the data would impact more than just the performance hit of having to perform a more expensive lookup, the var directory should be used instead.
config	This directoy may continue configuration files that are unique to a given caboodle. However, this directory is deprecated and you should use the etc directory for all new configuration files.
etc	Configuration files unique to a given caboodle amongst multiple caboodles synchronizing other components via a version control system. Since it is not appropriate to version control this file in a repository shared by other caboodles, it is sometimes helpful to manage these files using plans with compilers that can be directed to produce files in this directory based on symbolic variables and conditional compilation. See the .nb and plan directories.
exit	Commands that communicate a result via their exit code only. Unlike servants, these commands are normally not designed for use with NodeBrain. However, their exit code may identity the state of a monitored element, making it easy to map the exit code into a NodeBrain assertion.
kit	Used to manage kit dependencies. This directory is reserved for the nbkit command and should not be used by other kit components.
lib	Libraries and Perl modules supporting other kit components. As with all caboodle components, these components must be referenced using a relative path to maitain portability of the caboodle.
log	Log files for agents and other kit components. NodeBrain agents normally manage the rotation, compression, and deletion of their log files. When including other log files here, remember to provide the necessary management to avoid filling up your file system. Consider using the Caboodle agent to manage additional log files unless you have a more convenient method.
message	Used by the Message module and other modules using the NodeBrain Message Log API. Do not use this directory for other purposed.
msg	Used by alarm adapters (e.g. adapter/mail.alarm) that lookup and include a description of the alarm condition and response instructions. Subdirecties are defined for logical sets of alarms identified by the first three or four characters of a message identifier. For example a message CAB0001 would be described in the CAB subdirectory in a file named CAB0001. Within the message set subdirectory (e.g. CAB) additional files provide header, footer, and missing file text.
out	Output files produced by commands issued by NodeBrain when the output is not redirected. These files are retained for a few days for troubleshooting.
pipe	FIFO files for sending commands to Pipe nodes in NodeBrain agents or for communicating between other caboodle components.
plan	Contains a subdirectory for each plan, including the XML document, plan relationship files, and normally any files generated from the XML document by the associated compiler. In some cases the generated files go to another directory (e.g. \fPetc\fP) that does not share the same version control repository used by the plan directory.
queue	This directory contains subdirectories for Peer module gueues. This mechanism is deprecated and a future release of the Peer module will switch to message logs. NodeBrain message logs provide a more efficient method of sending events between agents and are currently supported by the Message module. See the Message module manual for more info.
security	Contains certificates and access lists.
servant	Contains servant commands that output NodeBrain commands to stdout. Commands that do not conform to this standard belong in bin, adapter, or exit. Servant commands may optionally accept commands from NodeBrain on stdin and report error conditions on stderr.
setup	Setup components. A kit may provide components in this directory for setting up an application.
socket	Local domain socket files for communication between NodeBrain processes using the Peer module. This directory may also be used for communication between other caboodle components that use local domain socket files.
user	Application user files. This directory is for storing user preferences and other user related information. There is no recommendation on how to organized user data in this directory.
var	Data files used in the normal operation of a NodeBrain application. Use the cache directory for temporary caching of data obtained from a more authoritive source.
web	Web content and scripts for web based tools. Individual tools should use sub-directories. For example, the NodeBrain planner uses the "planner" subdirectory and the Webster modules uses the "webster" subdirectory by default.

adapter, bin, exit, lib, msg, plan, servant, user, and web

When a NodeBrain application is distributed over multiple instances of like caboodles, a version control system may be used to provide synchronization of NodeBrain rules and other caboodle components. Using this approach, the recommended directories are checked out at each instance of the caboodle. A caboodle is then a working directory where only a subset of the directories a under version control. Changes at one instance of the caboodle can be commit to the repository with an update performed at the other instances to pick up the same changes. NodeBrain application used to monitor a group of like servers that required the same set of monitoring rules and components would be a good candidate for this approach. In this case it is best to identify a master caboodle where the updates are applied first. This helps to avoid conflicts that can easily occur in the plan XML documents because of the way the NodeBrain planner time stamps some of the XML elements.

[1] NodeBrain Home Page

[2] Caboodle NodeBrain Kit Manual