DCAF Module/Feature Wish List

[MattP]

This is the place to let us know what features and/or modules you wish existed in DCAF.  One idea per comment, please.  If you would also like to see something that has already been mentioned, please press the star button to give kudos to the comment.

The DCAF development team will keep an eye on this list, but we can't make guarantees as to whether a request will get implemented.  

[MattP]

DDS module to interface with the RTI DDS toolkit (on Windows and cRIO)

[MattP]

---

@MattP wrote:

DDS module to interface with the RTI DDS toolkit (on Windows and cRIO)

This module is available in beta form now at https://github.com/LabVIEW-DCAF/dds

[KeenanJohnson]

I would prefer that the configuration file existed in some form that is easily diff-able. If you have any sort of code review, process, using the current configuration file is not nessecarily easy.

[MattP]

---

@KeenanJohnson wrote:

I would prefer that the configuration file existed in some form that is easily diff-able. If you have any sort of code review, process, using the current configuration file is not nessecarily easy.

---

It's currently an xml file with serialized class data.  Is there a particular other format that would contain the same information but be easier for your process to work with?

[KeenanJohnson]

I would prefer that the config contain only the source "config" information, and the entire serialized class.

For instance, if I change which channels are logged in the TDMS module, I want the review to be able to just diff a file and see the changes in channels. However, because the entire class is serialized, there is a lot of extraneous data, that doesn't contain line breaks, making it incredibly difficult to verify.

[MattP]

Would having the equivalent of Pretty Print for the XML be sufficient (make it easier to separate out the data you care about vs. the extraneous data), or do you actually need the extraneous data removed?

It's pretty straightforward to prettify the existing format, it would be a major breaking change to switch to a different format.

[KeenanJohnson]

Cleaning up the XML would certainly help, but for my usecase, it would certainly be preferable to strip out the generate data entirely.

[MattP]

Added issue to Github to track the prettifying part of this request: https://github.com/LabVIEW-DCAF/TagEditorCore/issues/273

Changing the format entirely is not currently happening, but is something we'll keep an eye on.

[brindle]

A standard text import/export (like "File Import/Export" in Standard Engine Tags)  feature set across all modules.