I'd like to split the C code into (a) essential runtime files (b) optional/test runtime files.
Of the list of current files: daffodil_argp.c daffodil_argp.h daffodil_main.c infoset.c infoset.h stack.c stack.h xml_reader.c xml_reader.h xml_writer.c xml_writer.h I believe the infoset.c/h are "essential" in that 99% of all applications using C-generated code will want what is in them. The other files provide a command line allowing one to request parse/unparse behavior and interaction with an XML representation. These are "artifacts" of interacting seamlessly (and frankly, wonderfully) with the Daffodil test infrastructure based on TDML. While users might want to couple this C-based code generation with XML, I think there's some natural tension between the ultra-lightweight nature of C-code and the expensive verbosity of XML. Certainly, some people will want to use the C-code and almost nothing else. Just parse data and fill in C-structures, and equivalent unparse maybe. So while all this code is small by modern standards, I think infoset.c/h should end up in libruntime2 (essential for applications), and the remainder can/should end up in libruntime2cli which is 100% optional for applications. I expect both libraries to grow substantially over time as more runtime2 functionality is filled in. That's why I think we should separate them now. To clarify what goes where. Keep test infrastructure isolated so it doesn't "leak" into the essential runtime, etc. Thoughts? [cid:b1c6dcab-da6c-40ac-8151-bc6c5b0eea46] Mike Beckerle | Principal Engineer [OWL Cyber Defense] P +1-781-330-0412 W owlcyberdefense.com<http://www.owlcyberdefense.com>
