MOOT To-do

Best guess at difficulty is indicated by number of *

Code-like data (e.g., filter parameters) * *

For all file types handled by MOOT to date, MOOT itself creates the binary version of the file, typically by invoking some Flight Software service. In the case of filter parameters and other CDMs (Compiled Data Modules?) this is not practical. The procedure to make a binary is to compile code, which can only be done on a Sun machine, whereas MOOT runs only on Linux. One could in principle design a compile server for MOOT to invoke, but this would be a lot of work. Another approach (my preference) would be to provide a MOOT service to register such files which would take as input

• A reference to the source, so it can be archived like other sources
• the fmx key of the already-added file or a reference to the binary so that MOOT can do the fmx add.

The MOOT code to be written would not be especially difficult; what will take time is working out the details of the interface and figuring out exactly which entity invokes the service and when.

Resources needed: Consult with FSW (Tony?) and Online.

Upstream expansion * * * *

MOOT needs enhancement to handle processing and data upstream of LATC input and offline calibrations. This is difficult because it is open-ended and requires close collaboration with subsystems, particularly CAL.

Resources needed: Face-to-face time with subsytem representatives (must include CAL) to work out detailed requirements and determine who is responsible for what.

Offline calibrations *

Change the procedure to register new calibrations to use MOOT's OfflineCalib table; change Gleam code to fetch data from this table within the MOOT dbs rather than from the current (calib) database/metadata table. Some of the details are discussed in a separate document concerning MOOT and Offline.

Offline access to information MOOT maintains other than offline calibrations. * *

In particular, need to access some parts of configuration (e.g., splits) and code-like data such as filter parameters. Some of the details are discussed in a separate document concerning MOOT and Offline.

Mirror file archive * *

When a file is registered with MOOT, which is only permitted at the master database located at SLAC, a copy of the file is archived in dedicated afs space. If applications like Recon need to be run attached to a slave database, or even if the master database is used but the process does not have access to SLAC afs space, some procedure will be needed to keep remote archives current.

What MOOT does now

The above list is best considered in light of capabilities of MOOT to date.

Files: MOOT can keep track of LATC configuration files, lci scripts and thermal control parameters. They can be registered with MOOT (entailing creation of MOOT database entries, conversion to binary form, and issuing fmx add command), and, given an fmx key for any of these types of files, MOOT can recover the source (which it archives). It also can build a LATC master file and, given the fmx key for such a file, can recover the individual LATC source files referenced by the master.

Mirroring: Database mirroring has been demonstrated with lat-mandos as master and lat-tulkas as slave. However there is as yet no procedure for mirroring the file archive associated with a master database.