Eventually Daffodil will support multiple code generators. I have already sent a pull request to generalize Daffodil's CLI so we can call "daffodil generate <lang>" for additional languages. Now I want to discuss renaming daffodil-runtime2's module, package, and class names to new names that are more similar to and yet distinguishable from other code generators' modules, packages, and classes.
Daffodil's developers envisioned that Daffodil would have multiple backends/runtimes so they used "runtime2" as a placeholder name for whatever the next backend would be. That turned out to be a C code generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2" in many places within it. However, the use of "runtime2" as a name has to stop if we want Daffodil to generate code for additional languages. We can't have "runtime2", "runtime3", etc., since users will have no idea which runtimes correspond to which languages. As I see it, there are two choices for the C code generator's new module name. We can say 1) daffodil-c-generator or we can say 2) daffodil-generator-c, that is, "daffodil-<language>-generator" or "daffodil-generator-<language>". I originally was going to say daffodil-c-generator like how I say "Daffodil's C code generator" in English but I've rethought that and realized that daffodil-generator-<language> will group multiple code generators together, encouraging developers to update them together and eventually move any common code/TDML tests to "daffodil-generator". If developers agree, I'll start work on the necessary module/package/class/wiki changes and send a pull request (after the OSGi refactoring if it's going to be merged very soon). John
