Initial rust implementation

[jbangelo]

I scaled back my initial intentions, this is a few small tweaks on top of Gareth's SBP message generator work. I added a sender ID field to each full message struct, and added a very bare bones SBPMessage trait which has a message type constant, and functions for getting and setting the sender ID.

In addition to the message structure I added a simple parser type that reads through a source and tries to extract an SBP message. It's similar to the C parser, except that it buffers data, to try and avoid system call overhead.

Currently there is only parsing capabilities implemented. Eventually it would be nice to add a function to the SBPMessage trait to convert the message into a Vec<u8>, essentially a complete SBP frame.

[jbangelo]

Here are some remaining open questions I have:

1. Do we want to publish this to crates.io immediately? (Could see an argument to work with it a bit internally before publishing)
2. If we want to publish to crates.io, do we want to do that manually or have travis do it?
3. Do we see much benefit in generating tests from the YAML spec?

[jbangelo]

Here is a todo list:

• Error handling could be improved. More descriptive error states could be added to make it easier to tell what failed (i.e. CRC failure). Do we want to leverage an error handling library, like Failure?
• Add SBP output functionality.
• Move away from byteorder crate for parsing primitive types. The primitive types should all have a from_le_bytes() function as of version 1.32.0

These don't have to be addressed in this PR, but should probably be tracked somewhere. As github issues maybe?

[silverjam]

On Jul 22, 2019, at 9:31 AM, Joseph Angelo ***@***.***> wrote: Here are some remaining open questions I have: Do we want to publish this to crates.io immediately? (Could see an argument to work with it a bit internally before publishing)

I think we can go either way here, I haven’t seen any external demand for this, so publishing would be for our own internal convenience. Also, I’m not sure it adds that much convenience since Cargo can easily build and use crates directly from GitHub. So, the benefit of publishing would just be an easier installation line in `Cargo.toml`, and having the docs published on docs.rs <http://docs.rs/> automatically. If we publish, we can also state in the release that it’s a pre-release or alpha, and state explicitly what the functionality is, in order to manage expectations.

If we want to publish to crates.io, do we want to do that manually or have travis do it?

All other publishing is manual at the moment, so it makes sense for this to be too, at the moment.

Do we see much benefit in generating tests from the YAML spec?

If it’s not terribly hard I don’t think it’ll hurt since it would provide a better idea that the parsing is correct across all of the message types. If we have some other way of convincing ourselves that the parsing is correct (via sbp2json output like we did for the Python JIT support) then I think we can avoid it.

[silverjam]

On Jul 22, 2019, at 9:59 AM, Joseph Angelo ***@***.***> wrote:

...

These don't have to be addressed in this PR, but should probably be tracked somewhere. As github issues maybe?

GitHub issues that don’t get tracked internally don’t tend to get worked on :-)

[silverjam]

Do we really need a beta version of nom?

[jbangelo]

Not any more. Apparently version 5.0 has been released since I started work on this :)

[silverjam]

Ok, let's fix this up and merge.

[jbangelo]

@silverjam I'll leave figuring out about publishing to crates.io for later then. I'd prefer to get at least one internal project using this to fix out the major issues before pushing it out to the general public.

And for the tests, do you want to see them in this PR? I can work on adding them, but it'll take some time.

[silverjam]

LGTM, we'll add generated tests in a subsequent PR

[silverjam]