An issue has come up and I want to discuss a possible idea to help our users manage this.
Products have embedded Daffodil. Those products do not provide means for setting daffodil tunables. But we know some of the tunables are important to enable a schema to work - e.g., size limits on regex matches for example. A given schema may want to tighten these down, or open them up. But daffodil is now embedded in products that do not provide means to set the tunables. These products are regulated. Changing them to upgrade daffodil to a new version is relatively easy. Adding new features to them triggers a regulatory review. So here's the idea: Add a feature so that tunables can be set from inside the schema. E.g., a top-level annotation like <dfdlx:setTunables ..../> That would go at the top level of the schema. I also think that if you use a schema that requires a jar plugin (layering plugin, UDF, charset, or validator plugin) that the jar file should be automatically loaded by Daffodil without the user having to worry about setting up classpaths properly before calling Daffodil via API. I found on stack overflow that it is possible for a java program to extend the classpath dynamically. https://stackoverflow.com/questions/271506/why-cant-system-setproperty-change-the-classpath-at-runtime/1198693#1198693 and https://stackoverflow.com/questions/402330/is-it-possible-to-add-to-classpath-dynamically-in-java but Daffodil could also, given a plugin, scan its own "plugin-path" defined in the schema, and force load the jars directly rather than letting ordinary class loader classpath stuff do it. Taken together, these would let people add Daffodil to a product without having to add features for tuning, for specifying plug-ins, etc. The schema could specify all these things. Thoughts? Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com
