Allow nested parsers on MessageProducer level (v2)
This PR isn't for to be merged. It's a suggestion in the scope of work on #2073
Solution limitations:
- only parsers without lifetime can be included as nested parsers (for example DLT parser cannot be nested)
The previous version is here #2077
Something, that I didn't expect to be honest :/
Test inputs:
- same file
- same workflow
- same OS (linux)
- measurement starts after MessageProducer has been created (all parsers are created, all stuff are ready)
Test workflow:
- open chipmunk
- open file
- reopen file 6 times (without closing chipmunk, same instance)
The major approach is: that the parser doesn't own any nested parsers, but still can request additional (nested) parsing. At the same time, only the initial parser knows how a complete message should be represented. The Message Producer doesn't know it, the initial parser - knows. That's why the initial parser has a way to request an addition (nested) parsing.
At the same time, this solution gives flexibility and can be easily scaled.
To compare two ways: Parser owns nested parser(s)
- addition (nested) parsing happens inside the initial parser. It might cause problems with error handling, because now the work of the initial parser depends not only on itself but also on the nested parser's work.
- the work of the nested parser is out of the control of MessageProducer. For example, if we would have some configuration for the nested parsing approach (like disable/enable) that logic will go inside the initial parser; in the other hand, if an initial parser doesn't own nested parsers and requires additional parsing - MessageProducer can keep such settings under control.
Parsers doesn't own nested parser(s) and requires parsing
- MessageProducer keeps control of error handling of nested parsers
- MessageProducer can be configured to enable/disable nested parsing
In the same time a weak point of suggested solution - an initial parser should keep in memory result of nested parsing
Solution has been mentioned in the issue #2294 We can close all PR approaches for now and group them in that one issue
Solution has been mentioned in the issue #2294 We can close all PR approaches for now and group them in that one issue