stabilisation

[danieleades]

this SDK is listed on the website as a 'proof of concept'. What features would it need to be considered for stabilisation?

[julianoes]

I would say:

• Someone using and maintaining it. It seems like that would be you 😉.
• Full API up-to-date with proto submodule, and all auto-generated.
• Some testing done to make sure it works.

[danieleades]

and all auto-generated

when you say autogenerated, do you mean the proto bindings, or the external API as well?

[julianoes]

I would say that the Rust API is all generated based on the proto files. That's what we do for other language wrappers.

[danieleades]

I would say that the Rust API is all generated based on the proto files. That's what we do for other language wrappers.

what's stopping you from directly exposing the generated code?

i can see the argument for not exposing it directly. being able to guarantee greater API stability is one. Being able to smooth some of the rougher edges of the generated code being another. It does mean a lot more maintenance though. But you probably lose both of those advantages as soon as you start autogenerating the external API, right?

by templates, do you mean that you would use the proto files for both generating the bindings (using tonic) and separately generate the external API using templates?

[julianoes]

I guess that's what we do for other languages but if the tonic API is nice enough than that's also fine, I'd say.

[danieleades]

I guess that's what we do for other languages but if the tonic API is nice enough than that's also fine, I'd say.

quick sketch in #31 - tl;dr: you can have both

[elpiel]

I've been maintaining the AeroRust mav-sdk crate for a while now and currently working on the v0.2 that will support MAVSDK v1.0 (PR AeroRust/mav#6).

You can check it out here:

https://crates.io/crates/mav-sdk/

It seems to me that there's no work done on this crate and I've decided to make one in the AeroRust organization.

[julianoes]

Hi @elpiel, thanks for the note! Do you think your work in AeroRust/mav could flow back into this repo here? Could we merge the efforts, or is it all based on very different design decisions?

[elpiel]

Hello @julianoes,
mav-sdk is one of the few crates being developed under the AeroRust community, but I would love to find a way to collaborate and support it under mavlink as an official wrapper for MAVSDK.

As for the design, my development efforts have been focused more on usability rather than the API and the particular code that's been generated.
I want to use this crate for other abstractions and build projects on top of it and MAVSDK-Rust just didn't have that.

[julianoes]

Sorry, I'm still confused. Let's have a call and talk it through, or chat on Slack sometime?

[elpiel]

Quick update: As of now, the mav-sdk crate cannot be considered for an official MAVSDK Rust crate as it doesn't align with the API of the rest of the MAVSDK implementations in other languages.

We agreed that mav-sdk can stay independent of the MAVLink organization and it can remain the more functional MAVSDK, which is usable and could form the basis for future developments in the MAVLink organization for an official MAVSDK in Rust.