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>
[cid:2a423dec-0558-414e-b369-14a24becc40f] 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>
