Filter and Friends Config Handling (Sketch)

In this revised document limit scope somewhat.

Clients and their needs

1. Establish parameter values to be uploaded

   Never will be (and should not be) fully automated.

2. Track parameters for, e.g. generating reports, and for certain types of analysis not necessarily done in the context of Gleam; also required for planning purposes before a configuration has been used.

Proposal

1. Parameters for new or modified filter configuration originate with or make their way to Flight Software and are embodied in a .h file.

   To be done: Nothing. This is the same as current procedure.

2. When the relevant package is built, or when the resulting .so's are added to fmx, one of the outputs will be an xml file containing in essence the same parameter information in the .h. (Most likely the implementation will make use of the pre-existing facility which can create an ascii dump from a .so.). The xml file will also be stored in fmx.

   To be done: Design xml format including protocol to handle versioning of dtd. Write the code to generate the file. Modify fmx to be aware of and handle the files.

3. Request a software build, including the new CDM(s).

   To be done: Probably nothing. Continue using current procedures.

4. After the build is complete, invoke MOOT function registerConstituents which takes as input
   • SBS key.
   • Specification of constituents of interest. Perhaps the right way to do it is to specify packages of interest. Or maybe it should just be 'all'.

   A first version of this function and MOOT dbs tables to support it exist and have been tested. Running the function creates entries in a new table, Constituents and keeps track of their association with the SBS key.

   

   To be done: Modify FMX_scanSBSmembers callback interface or add new function to fmxshr to make xml file available. Add ability to registerConstituents function to archive associated xml files.

5. Invent new precinct (call it Associate for now)
   • refers to lpa_db
   • contains associations (handler, filter-config, mode)
   • contains the list of active handlers

   To be done: Jim already has a suitable or nearly-suitable xml format for a vote file for the new precinct. Its description needs to be added to intent.xsd, the new precinct has to be added to the MOOT Precincts table, and there are probably some minor implications for MOOT code.

6. One could then specify the software key when building a new Config. MOOT wouldn't do anything with it other than make a bookkeeping entry or two. making it possible to retrieve the software key, and hence constituent name, version, etc., from the MOOT Config key. Using the information in the Associate vote file (also retrievable from a MOOT Config key) one could determine the filter associations.

If all of the above is accomplished, from a MOOT Config key it would be possible to retrieve

• Software key and thence information about all constitutents, in particular information about filter configuration instances, GRB, etc., including xml representation of intent.
• Filter association intent.
• hardware key, LATC input source, and intent (vote files) used to generate the hardware configuration (already implemented)

However from this static information it would not be possible to reliably determine which handlers were active; that can only come from the data.

Initial draft: 10 Jan 2008 Last revised: Thursday, 20-Mar-2008 18:39:34 PDT

J. Bogart