AIS NMEA messages

[Lachezar Lechev]

AIS messages

We're missing support for AIS messages and thankfully there's a crate build for them already!

I've already opened an issue regarding the integration in the NMEA crate (squidpickles/ais#8) and the maintainer is looking into no_std support for the crate (squidpickles/ais#9)

We should integrate the ais crate or use it as a dependency inside nmea.

As @squidpickles mentioned in a comment (squidpickles/ais#8 (comment)):

Probably do want to keep this existing on its own, too, as some folks (myself included) only have real use for the AIS portion at the moment.
However, we can look into another solution, instead of keeping the crates separate - enabling message parsing by features gates.

Features proposal

Here's a WIP list of features we can use to separate the different message parsing of the crate and allow people to only use a certain message(s):

• ais
• bwc
• gga
• gll
• gns
• gsa
• gsv
• rmc
• txt
• vtg

[Evgeniy Dushistov]

Here's a WIP list of features we can use to separate the different message parsing of the crate and allow people to only use a certain message(

Every new feature is not small thing, it is increase testing efforts (we need check 2^number_of_feature combinations),
it need documentation and so on. Is any reason to add such features?
Linker even without LTO can remove unused code, and removing dead code is default option for no_std builds.

[Lachezar Lechev]

It's still a matter of pulling the code and compiling it, even when optimizing. It would be nice to test all features separately, however, I don't necessarily think that we should.

I'm also adding this issue as part of #47

[Evgeniy Dushistov]

It's still a matter of pulling the code and compiling it, even when optimizing.

Not sure that follow you here. You mean that compilation of code for parsing one message is so slow,
that it is worth extra feature to disable it? On my machine in release mode compilation of nmea crate takes < 1 second,
why care about fraction of second?

It would be nice to test all features separately, however, I don't necessarily think that we should.

So if code don't compiled for user, because of feature X reference code hidden under feature Y,
it is not our problem? I suppose we should test all features combination with help of CI.

[Lachezar Lechev]

Not sure that follow you here. You mean that compilation of code for parsing one message is so slow,

@Dushistov Let me rephrase that - you can't optimize the parsing part because messages are dynamic. No matter what you pass inside, str, bytes, you will have the parsing of the different message types, i.e. it will not be optimized (see Nmea::parse()).
You're still going to have the code for parsing all message types inside the binary and if you have an embedded system with limited memory this can make a difference.

As an example, the uuid crate can parse UUIDs but can't generate them if you don't allow a given feature (https://docs.rs/uuid/latest/uuid/#dependencies).