I was curious when review the last pull request update and did a little performance testing on the format info stuff. PCAP was virtually the same, and I think DISv6 saw <10% decrease. So not great, but not terrible. I didn't look at any text based formats. But I agree, it's more important to get the fix in and optimize where necessary.
The query-style "hack" doesn't seem too bad to me. Though, rather than just always selecting the first and silently ignoring others, it might make sense to change the existing compile time SDE to an SDW, and then add a runtime SDE check if an expression ever evaluates to two instances. That way people can still do things that *look* like query expressions (e.g. the NATO bug) but that might actually never occur. I don't think there's a *ton* of work to get query style working, but the above change is definitely less work and would be easier to get done for 2.1.0. On 01/04/2018 11:22 AM, Mike Beckerle wrote: > The "format info" PR may have performance impact that would need to be fixed > before 2.1. That's ok. I'd rather merge it, then put it under the microscope > to > identify and fix performance issues rather than keep this large change > outstanding any longer. > > > re: NATO fix - yes query style expressions are the general capability that > fixes > this. > > > I have a "hack" fix for this - It simply removes the check when the schema > compiler detects /foo/bar when there is more than one bar element. Without > that > check, then at runtime you will always just get the value of the first bar > element. > > > This is a small change, and can be reviewed at: > > > https://github.com/mbeckerle/incubator-daffodil/pull/2 > > > This is all in my incubator fork, i.e., not a real PR on daffodil, because > I've > built this change on top of other work not yet merged. > > > I'm curious how much more work there is to really do query-style expressions. > > > -------------------------------------------------------------------------------- > *From:* Steve Lawrence <[email protected]> > *Sent:* Thursday, January 4, 2018 11:00:33 AM > *To:* [email protected]; Mike Beckerle > *Subject:* Re: Roadmap for next Daffodil releases > I think this seems like a reasonable roadmap with the right priorities. > > Regarding 2.1.0: > > I think all our current pull requests (except for maybe the packed/zoned > stuff?) are close to being merged in and can make 2.1.0. > > I've got a patchset ready that changes to the apache namespace/license > which we can apply now that the SGAs are in. Once the existing PRs are > merged, I'll rebase the patchset onto that and do a pull request. > > Regarding the NATO bug fix, is the right fix for this to support query > style expressions? The InfosetImpl already has the changes necessary to > support them. So it should just require changes to DPath to expect and > allow Sequences of DINodes rather than a single node. And most DPath > functions should just error if there is more than one element. It's > probably just the array handling/indexing that changes, and additional > validation that all types of same named elements are the same?. I don't > think the changes are trivial, but they should be mostly contained to DPath. > > - Steve > > On 12/22/2017 01:17 PM, Mike Beckerle wrote: >> We've had some people asking what our road map is for next releases. >> >> >> Here's my proposal. I'm open to suggestions to change, reorder, add, etc.. >> The release numbering schema is of course subject to change. >> >> >> My planning horizon is about 6 months here. >> >> >> Release 2.1.0 - to contain critical patches needed by 2 of our user >> communities (LWAP project, NATO). >> >> * Goal Timeframe: Jan 2018 >> * This should be our first Apache Incubator release as we have all the >> SGAs on file for Apache now. >> * LWAP bug fix (DAFFODIL-1864) is in & done >> * NATO bug fix >> (DAFFODIL-1869<https://issues.apache.org/jira/browse/DAFFODIL-1869>) has yet >> to be explored/reproduced. This is way overdue, as they reported the issue >> last spring/early-summer. >> >> >> Release 2.2.0 - Three new important features >> >> * Goal Timeframe: March/April 2018 >> >> * BLOB support (DAFFODIL-1735) - enables large image file formats >> * pre/post processor support (DAFFODIL-1734) - enables IETF format needs >> like line folding, and base64 encoding >> * message streaming API (DAFFODIL-1065, DAFFODIL-1526, DAFFODIL-1799) >> * enables unbounded stream of input messages for parsing, output for >> unparsing >> >> >> Release 2.3.0 - Interoperability >> >> * Goal Timeframe: June 2018 >> * Implements features needed to demonstrate high degree of interop of >> the two primary DFDL implementations which are IBM's and Daffodil. >> * Large number of JIRA tickets associated with this. Not going to >> enumerate them here. >> >> >> >> Time frames are of course subject to the number of contributors working on >> it. >> >> >> My guesses/goals for time-frames are based on wanting to do a release about >> every 2 or 3 months, and roughly the current number of active, up-to-speed, >> contributors. Our hope of course is to gather new contributors, which would >> hopefully allow us to do more. >> >> >> The above really only discusses functional changes in Daffodil visible >> features. >> >> >> The stretch goals for these releases include making progress on any of these >> areas: >> >> * changes to reduce memory footprint and improve performance of the >> schema compiler (DAFFODIL-1444) >> * usability improvements (diagnostics - 69 JIRA Tickets, debugger - 14 >> JIRA Tickets) >> * new DFDL language features (DAFFODIL-1782) to support integer >> representations of logical strings with table-based translation. (Needed for >> some schemas like STANAG 5516, VMF) >> * Expanded documentation of Daffodil internals - in code comments, and >> outside of it (wiki) >> * DFDL tutorials and example schemas >> * Reduce bug backlog (198 JIRA Tickets) and the 236 TODOs and FIXMEs in >> the code (DAFFODIL-1569) >> * Some code cleanups/simplifications (45 JIRA Tickets labeled "Clean >> Ups" component) >> >> >> >> >
