This should include the ability to store/retrieve the DMR++ objects/responses. This would be a priority over the DDS/DMR constrained responses.
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.
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.