Project

General

Profile

Steps needed to Implement SAMmetadata in art

The steps are broken down by the classes or services in which they appear. This is not necessarily the order in which these enhancements ought to be coded.

Overall issues:

  • How do we determine whether SAM is being used to get the input files, and how do we implement the choice in various places?
  • Where does SAMDatasetDefinition come from when needed? Who makes sure this is in place when SAMProtocol service is instantiated?

IntermediatePostProcessor

  1. Create a method taking a parameter name that will flook on the command line for the --name=whatever and if finding it, inject that into the ParameterSet for the job. We are already doing this for some parameters; we should factor that code out so that we do not have to repeat it.
    Say we call that method injectFromCommandLine(std::string const & name);.
  2. Invoke injectFromCommandLine() for each of the roughly a dozen new command-line-settable parameters we have defined.
  3. Figure out what to do about the parameters that are to be injected into module ParameterSets.

The first two of these are simple. The third could involve moderate design thought.

SAMmetadata service

  1. Create the SAMmetadata service class using the usual template for services.
  2. Create the KeyValuePair class.
  3. Write the method that delivers the vector of KeyValuePairs.

None of these are at all complex; this whole service can be written quickly.

OutputModule

  1. Write a formSAMmetadata() method, which gets the vector of KeyValuePairs from the SAMmetadata service and adds the output-module-specific items needed.
  2. Create a getSAMmetadata() method that inheritors can invoke; this does not necessarily even have to be a method if there is a protected
    vector of KeyValuePairs formed by formSAMmetadata.
  3. Add to doCloseFile() method something that invokes the outputFileClosed() method of SAMProtocol.

None of these are very complex, although the additional module-specific key value pairs will require some care in creation.

RootOutputModule

  1. Invoke the getSAMmetadata() method of its base class (or stare at the metadata directly).
  2. Write, at the appropriate time, the SAM metadata into the DB in the file. We already have an example of doing this, using a very simple collection of key/value pairs, so this will be trivial.

This is close to trivial.

RootInputModule

Note that some of these steps logically ought to be done in the InputModule base class. Due to the DRISI bollix, which we don't intend to fix as part of the SAM metadata first-round implementation, most or all of the input-side steps will be envisioned as happening in RootInputModule. If we choose do do some step in the base class that should neither be more nor less difficult at this point.

  1. Logic for deciding how we are getting our input files: SAMProtocol and file transfer or a list of files. This determination probably will have been made elsewhere, but here we at least have to pick up the answer.
  2. Code (in the SAM case) to invoke the SAMProtocol service's getNextFileURI method, and remember the URI.
  3. Reaction to NO_MORE_FILES as if the last file in the list was now done.
  4. Code to deal with the various possible anomalous statuses returned by getNextFileURI.
  5. Pass the URI to SAMFileTransfer service: SAMopenAndCopyToScratch()
  6. Deal with various possible non-successful codes from SAMopenAndCopyToScratch(). Abort possibilities should probably go down the same path as that already done if a file on a list has problems.
  7. Open the provided file, as if it were the next on the list.

Other than the logical determination of where we are getting files from -- which is probably done elsewhere -- the only time-consuming part of this is dealing with various possible anomalous return statuses. And for the first round of implementation, any simple semi-sensible reactions will do, although it is unfortunate that this logic, which ought probably to reside in the base class, will instead need to be factored out but invoked by the RootInputModule class.

At any rate, there seem to be no difficult issues.

Summary -- What to Think About Next

Since it looks like none of these classes have any particularly difficult code to write, things should go smoothly once we resolve the two issues mentioned at the top of this page.