In the PR review of the changes for DAFFODIL-2221, a key observation is
that the ipv4 and checkdigits layers defined there are in need of far too
many Daffodil internal data structures. We don't expose PState/UState, and
especially don't want to expose the unparser suspensable operation stuff as
a supported API.
So those examples need to be refactored so that the layer definition is
highly isolated from almost all aspects of Daffodil internals.
I believe a layer should be able to be defined using only:
0) the name of the layer transform
1) what are the QNames of any DFDL variables the layer needs to read.
(Could be none)
2) what is the QName of the DFDL variable the layer needs to write.
3) a method that given a mutable ByteBuffer, and a parse/unparse flag,
computes
(a) the checksum/CRC/parity output (and returns it) - both for parse and
unparse.
(b) when unparsing, modifies the byte buffer with the actual bytes to be
output, if it is different from what is provided to the method.
Everything else should be daffodil-internal framework code.
e.g.,
final class MyExampleLayerTransform()
extends ByteBufferExplicitLengthLayerTransform("myExample",
Seq("pre:nameOfVarRead"), "pre:nameOfVarWritten") {
override def doTransform(isUnparse: Boolean, bytes: ByteBuffer): Int = {
???
}
}
Or something along those lines. This is only for small-message cases. A
data format with large blobs to be checksummed, or CRCs over large
file-sized data, needs a different abstraction than a byte buffer, and of
course there are more length kinds than just 'explicit'.
On Sat, Sep 25, 2021 at 8:31 PM Mike Beckerle <[email protected]> wrote:
> Please see:
> https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Dynamically+loading+Layer+Transformations
>
> Also: https://issues.apache.org/jira/browse/DAFFODIL-1927
>
> See related PR: https://github.com/apache/daffodil/pull/643 which is for
> https://issues.apache.org/jira/browse/DAFFODIL-2221
>
> Please add comments or directly edit that wiki page, or discuss in this
> email thread if you prefer.
>
>
