Agreed on deprecating setting variables in the Compiler. It really just doesn't make sense to be doing that.
Definitely seems reasonable to add the ability to set variables when calling parse/unparse as that's the most threadsafe way to handle it, and feels natural to me. Note that we still have other mutable state in a DataProcessor like tuanbles, validationeMode, debbuging, that we might want to think about as well. Though those do feel a little different than variables. The idea of having to call a clone() method to change a DataProcessors variables seems a little unintuitive to me. But if we take a more functional approach and make it entirely non-mutable, it maybe seems better, something like: Any thoughts on what the API might like going the parse route vs the DataProcessor route? On 3/25/20 10:55 AM, Beckerle, Mike wrote: > Why does the API for Daffodil have > > Compiler.setExternalDFDLVariable(...) > and > Compiler.setExternalDFDLVariables(...) > > on it. > > I believe we should deprecate this. > > Compilers are parameterized by some of the tunables I understand. > > But the external DFDL variables? These cannot affect compilation. The schema > compiler needs to know statically the information about variables found in > the > schema itself in the dfdl:defineVariable statement annotations. > > But the compiler doesn't need external variable bindings. In fact if it did > know > and use them, it would be building assumptions into the compiled schema that > it > shouldn't be building in. > > Setting external var bindings on the Compiler just causes problems when that > compiler instance is reused in a context where those settings aren't > appropriate. (JIRA DAFFODIL-2302 is one such problem) > > I believe setExternalDFDLVariable(s) methods should be deprecated, and > external > variables bindings should be an optional argument to the parse/unparse > methods. > > The setters cause thread safety issues because the DP is stateful, even > though > we want multiple calls to parse/unparse to be executable on different threads. > > Consider: if we allow ordinary setExternalDFDLVariables and add a > resetExternalDFDLVariables to clear them, then imagine one wants to make two > parse calls on separate threads with different external variables bindings: > > so on main thread..... > dp.setExternalVariables(...bindings 1...) > spawn the thread 1 > on the thread 1 > dp.parse(....) > back on main thread > dp.resetExternalVariables() // race condition. Did the parse call read > the > external variables before this reset or not? > dp.setExternalVariables(...bindings 2....) > ..... > > However, if we make the external variable bindings an argument to parse, we > avoid all of this. > > Alternatively, since DataProcessor has setExternalDFDLVariable, we can > prohibit > multiple calls on the same DataProcessor object simultaneously. We can > provide a > clone() method that preserves the loaded/reloaded processor, but constructs > another DataProcessor object, thereby allowing separate external variables > state > per DataProcessor instance. > > > Comments? > > > > > > Mike Beckerle | Principal Engineer > Owl Cyber Defense <http://owlcyberdefense.com> > /is now a part of Owl > <https://owlcyberdefense.com/news/owl-cyber-defense-tresys-technology-announce-merger/>/ > P +1-781-330-0412 > W owlcyberdefense.com <http://www.owlcyberdefense.com> >
