[
https://issues.apache.org/jira/browse/DAFFODIL-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Beckerle closed DAFFODIL-1458.
--------------------------------------
Resolution: Won't Fix
pointless wish list item.
Many varieties of APIs for Daffodil are desirable. Unless there's a specific
need for this one, we don't want to list it. It's cool that this could be done,
but not worth a tracker/ticket because that requires people to sift it
periodically.
> pull-style unparser
> -------------------
>
> Key: DAFFODIL-1458
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1458
> Project: Daffodil
> Issue Type: Wish
> Components: API, Back End, Unparsing
> Reporter: Michael Beckerle
> Priority: Major
>
> Using java.io.PipedOutputStream, java.io.PipedInputStream, and InvertControl,
> we should be able to implement a pull-style unparser where normal reading
> from some inputStream in effect drives the unparsing to an outputStream that
> feeds into the input stream.
> {code}
> val inputStream: InputStream = DataProcessor.pullUnparser(infosetCursor)
> {code}
> Reading bytes from the inputStream will force pulling of buffers of data from
> an internal output stream and co-routines with the unparser that is
> populating the outputStream.
> A throw of an UnparseError must occur on the main co-routine if the
> pullUnparser encounters such. This will occur when data being pulled contains
> the representation of the element whose unparsing creates the error, not
> before.
> Ex: if there's 100 unparsed bytes in the buffer, but what's next should be
> the representation of an outputValueCalc element whose expression caused an
> UnparseError. Well the 100 bytes should be delivered all the way to the
> inputStream and from it to the application reading from it. Only on the next
> read call on the inputStream should that cause the UnparseError to be issued.
> However, the error thrown may aggregate multiple UnparseErrors &
> RuntimeSchemaDefinitionErrors, as not only the first one whose element
> creates the error should be reported, but potentially there are others from
> unparsing of later elements (into buffers) that are relevant to understanding
> what went wrong while unparsing.
> A buffered output stream "block size" can avoid excessive context switching
> by delaying the resume of the consuming co-routine (main, which is reading
> from the inputStream) until a block of data has been produced by the
> unparser. (Note that the minimum block size would be 1 byte, even though
> unparsing may occur at the level of individual bits.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
