Open ekuinox opened 1 year ago
There's definitely a place for improvement here. It makes sense to keep our current validation process - if we don't have a parser for the sentences - return an error, however, we could improve the vendor specific sentences although not sure what you envision for it.
PGRMZ is the only Vendor specific sentences and I think it's a good time to discuss how we should handle them
For example, if the talker is P
and the following vendor code is ABC
and the following buffer is abcdefg*hh
, I want NmeaSentence
to be
NmeaSentence {
talker_id: "P",
message_id: SentenceType::VendorExtension("ABC"),
data: "abcdefg",
checksum: hh,
}
I would like to make sure that PGRMZ
, which already has an implementation, can also fit into this form once without being treated as special.
Ok, so my current line of thought is to allow a callback for parsing unknown sentences, which will be great to the user as they will add the vendor-specific sentences instead of us. A few things to consider:
nom
Regardless of the sentence type, if it is correct as NMEA0183, one would expect it to be parsed using
nmea::parse_nmea_sentence
, but parsing fails if it is not included inSentenceType
.I don't have any ideas about what to do with the existing
PGRMZ
, but would it be possible to add an enumerator likeVendorExtension(&str)
to theSentenceType
to handle it?