How to pace initial contribution for Rust SDK?

[AnotherDaniel]

Hi all (@stevenhartley et al), I'm essentially done an initial version of the Rust SDK - some process ends being tied up on our end, etc, but getting close enough to ask this question:
How would you like me to make this available? One summary PR that includes the entire thing (matching the Java SDK in functionality)? Or rather a batch of individual PRs, maybe grouped by submodule (uuid, uri, cloudevent, transport etc)?

[stevenhartley]

Hi @AnotherDaniel , Tamara an I are finishing up the Java SDK and going back and forth on the UUri updates, it would be better to wait till we merge ours first then you can dump the rust SDK in one PR under the Rust project still for the same goal of uProtocol 1.5 (what we are calling these changes).

[stevenhartley]

What are you using for your test framework? Do you have the test cases with 100% code coverage? We'll need that before we merge the change as well, if that is too much for all modules then it would be better to merge by sub model in the order:

• UUri
• UUID
• CloudEvent
• uTransport
• RPC

[AnotherDaniel]

Rust has unit test functionality built-in, what I did so far is I also ported all of the tests from the Java SDK along with the actual code. So I do have the same coverage as that one...

[evshary]

May I know whether there is a roadmap for Rust SDK release?
I want to implement our own transport layer but haven't decided to use Rust or Java. (I prefer Rust anyway)
It would be great if we could know the roadmap. Thank you.

[AnotherDaniel]

hi @evshary ! Since last week there already is a PR for the first version.
It is waiting for review at the moment - if you have any opinions, please let's have them! ;-) I'll speak with @stevenhartley to see if we can speed up the merge.

One piece of info on the state of the uProtocol SDKs: the Rust one is currently aiming to implement the functional state of the Java SDK, as per this long-coming PR. There are right now some rather fundamental changes being implemented in the Java SDK, likely as continuation of PR#18, which will become available in 1 week or so if I understood Steven correctly. Once that is out, I will catch up with the Rust SDK, and this will likely become a longer-term stable v1.5 of the uProtocol suite.

[stevenhartley]

@evshary we have been finalizing 1.5 version of uProtocol (uprotocol-spec & uprotocol-core-api) so that we can role out the changes in all the language libraries. We have been updating the language libraries and specs at the same time to try and get the changes out sooner. Spec changes will be finalized this week with python, Java, C++, and Rust shortly after (in that order).

[evshary]

Hi @AnotherDaniel and @stevenhartley
Thank you for the answers. Looking forward to the release!

Spec changes will be finalized this week with python, Java, C++, and Rust shortly after (in that order).

Just out of curiosity, the first priority is Python, not Java, right? I thought Java was the first priority to support in uProtocol. Maybe I misunderstood.
We want to know whether we can use in the language we choose when there is a new version of uProtocol.

[stevenhartley]

Python was ready faster but I'm getting more help for have SDK updates this week.

[AnotherDaniel]

Closing issue - initial PR is merged into https://github.com/eclipse-uprotocol/uprotocol-rust/tree/uprotocol_1.5