dotMorten / NmeaParser

Library for handling NMEA message in Windows Desktop, Store, Phone, Universal, and Xamarin (Android + iOS), coming from files, bluetooth, serial port or any stream
https://dotmorten.github.io/NmeaParser/
Apache License 2.0
262 stars 89 forks source link

Added raw data access #10

Closed kwesolowski closed 9 years ago

kwesolowski commented 9 years ago

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.

dotMorten commented 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?

kwesolowski commented 9 years ago

@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?

dotMorten commented 9 years ago

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.

kwesolowski commented 9 years ago

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".

dotMorten commented 9 years ago

@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.

kwesolowski commented 9 years ago

@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.

dotMorten commented 9 years ago

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.