Closed kwesolowski closed 9 years ago
I'm not clear on what the need for this is? Seems to me we'll just be raising events for the same message twice?
@dotMorten Events are different:
So first allows logging raw frames to file or detecting "uknown frames". Even for known frames it is safer and more efficient to log raw data instead of rendering frames from already parsed data.
Or maybe we just missed other way to do it?
I think the better solution is to return an UnknownMessage for any message that wasn't a known message type (that also avoid having to distinguish between valid and invalid messages in two different events). I don't really see the point in returning invalid/incomplete frames. What use are these? We wouldn't even know if they are the complete message, so raising a message received isn't correct.
Returning UnknownMessage for unknown message types is not relevant to our problem (but good idea anyway). We use NMEA stream for navigation, and in parallel we must record whole NMEA stream for post mission diagnostics and postprocessing.
So introducing UnknownMessage
would still not allow us to log messages in its "almost raw form".
@kwesolowski Why wouldn't that be possible? The sample apps logs all the data messages to the output window. Only thing is that currently it skips the unknown ones, but proposed solution would handle that.
@dotMorten Ok, you are right - i can use ToString to convert back to single line format. I still feel bad with such roundtrips (we would need to store raw data/message parts in UnknownFrame).
I do not completely understand why you do not like "separate events", because with them, anyone can use only data he subscribed for (and therefore we can even pass newline separated messages not conforming to NMEA standard etc).
I was also considering creation of Stream Proxy duplicating all data read from port to file - so I can go this way to ensure all data is captured without modification to NmeaParser.
Logged issue #14. This is a solution that fits better with my API design in mind. The Library is meant to parse messages - not proxy things through to a secondary parser. An underlying custom stream could handle that.
We have made small addition to library for our needs (and fixed some minor code style/format issues), we would love for this addition to be integrated and release via nuget if you find this addition worth including.