Modify the MDS so that it supports the DMR++ response


This should include the ability to store/retrieve the DMR++ objects/responses. This would be a priority over the DDS/DMR constrained responses.

Two approaches:

  1. Subclass the MDS; subclassing means there could be a MDS version that is local to the dmrpp module, but when other code uses the GlobalMetadataStore::get_instance() method, what will it get? The instance made by the dmrpp_module or the instance made by the dap module? The code in bes/dap will have to get access to a MDS that knows about DMR++ responses/objects. That code is going to have to be able to build DMR objects that us Dmrpp<Type> classes.

  2. Add new functionality to the existing MDS software. I think this can work, but it means including classes from 'below' the bes/dap code down in bes/modules/dmrpp_module.

Ways to code add_responses() to support the DMR++ (could be done using either a hack of the exiting code or a specialization):

  • Add add_responses(DMRpp *, ...); it would write both DMR and DMR++ responses

  • Modify add_responses(DMR *, ...) such that it will test the DMR instance, see if it is actually a DMRpp instance and write both the DMR and DMR++ responses if so. Otherwise, if the DMR is just a DMR, it would write only the DMR response.

Ways to support the is_obj_available() and get_obj_response():

  • Specialize GlobalMetadataStore and add those two methods

  • Hack the existing code and add those two methods

Modify the remove_responses(), either in the existing code or a specialization.


James Gallagher


James Gallagher

Epic Link




Fix versions