This document attempts to describe the method behind the madness of the "Map" files used to update the Finger database. The next section gives an overview of the Finger database although it is assumed that the reader knows something about the cypress data model. Section 3 describes the format of the map files and Section 4 rationalizes said format by describing the operation of FingerTool. The last section describes the relevant operations provided by FingerOps that use these files.

The Finger database consists of two types of data: Data about machines and data about users. Various commands are provided to interrogate this database [1] particularly the Fingertool.

Building the database requires providing a "map" file in the format described in the next section and calling the relevant command as described in section 5. There is a map file for each type of data. These files are really just human-readable versions of the data in the database, not the real schemas at all. So I lied - sue me.

The first line of the file lists the attributes or properties of the relation concerned. These are double-quoted strings. These become pnames of atoms and eventually will be button names in the Fingertool. For this reason they should be as descriptive as possible while also being brief. Following each of these names is an atom giving a hint as to whether to build an index on that property. If there is to be an index, the atom value should be $Index otherwise it can be anything. An atom must appear after each property.

Following the first list is the entry for each entity. There must not be a blank line between the first line of the file and the first line of the first entry. An entry consists of the entity's name followed by (separate lines are not necessary but look pretty) a list of property-name, property-value pairs where the properties are those listed on the first line. Entries for entities should be separated by exactly one blank line. It is not necessary to give values to each property. Everything is a double-quoted string.

An example is:

The properties in the different relations (ie User and Machine) can be determined from the database. The Fingertool implementation builds the fingertool by determining what the properties are, and making as many buttons, appropriately labeled, as there are properties. These buttons are laid out as the user name/host button, the property buttons in alphabetical order and then the actions/last user button.

Hence the need to (1) provide more than just atoms when specifying the properties in the map file and (2) making the descriptions useful. This makes it easy to change that data in the database and have the changes reflected in the FingerTool.

The relevant commands are ReadMachineMap and ReadUserMap from FingerOps. Just feed your file, which should be in the format described above, into the appropriate routine in the interpreter. Note that if you wish to make an existing non-indexed field into an indexed field, you must set resetProperties.

WriteMachineMap and WriteUserMap are also available to dump the database in human-readable form.

There is also a command registered called pup-to-finger which takes [Indigo]<Portola>Pup-Network.txt, parses it and produces a file ///Temp/pup-net.text which consists all of the useful information from Pup-Network.txt in a form suitable for ReadMachineMap with reasonable guesses as to what should be indexed.

If you want to add a new field initialized to nothing for all entities, AddUserProp and AddMachineProp are for you (together with their counterparts DeleteUserProp and DeleteMachineProp).

1: [Cedar]<CedarChest6.1>Documentation>FingerDoc.Tioga