search

jamesmunns / postcard

A no_std + serde compatible message library for Rust
Apache License 2.0
930 stars 89 forks source link

RFC: Thoughts on Postcard 2.0? #128

Open jamesmunns opened 10 months ago

jamesmunns commented 10 months ago

Due to some of the dependency stuff, I am considering doing a 2.0 breaking change to the postcard crate. This would allow me to make public API changes to make dependencies, particularly for those that are required for flavors, like heapless, or embedded-io, to be versioned, so that updating them does not cause future breaking changes.

This would not be a breaking change to the wire format: Postcard 1.x and Postcard 2.x users would be able to mutually send messages with no compatibility issues, but there WOULD be breaking API changes, so some code changes could be required for updating.

As I see it, the options today are:

  1. Don't do a breaking change, but add support for new version of libraries like heapless and embedded-io
    • This will likely be awkward, and have complicated feature flags
    • I'd probably deprecate certain APIs (like to_vec() that is for heapless v0_7)
    • I don't really want to spend time on this.
  2. Do a breaking change to the LIBRARY API, but not the BINARY WIRE FORMAT.
    • This means we can't fix issues like #101, but we can fix the other stuff
    • I'll probably isolate the "flavor" impls better, either as feature-flagged modules, or maybe even as external crates.
    • This way people can update when they want, and if they really want to backport flavors (like for heapless-v0_8) to postcard 1.0, they can.
    • This is my preferred option
  3. Break both the library API AND the binary format
    • this would let me fix the char issue, but we don't actually have any other open issues AFAIK
    • this would be unfortunate, and FORCE users to update, and might cause compat issues.

If you use postcard, I'd like to hear your opinion! Unless someone is willing to do the work for option 1, or willing to sponsor the work for 1, or makes a suggestion for another option, I'll probably go with 2.

Tagging some related issues:

CBJamo commented 10 months ago

The cost of option 2 seems very low to users. Each project I update would only be looking at 2-5 lines to change, and the changes would be very similar from project to project. If it makes maintenance easier and opens the door to more features it seems like an obviously good choice to me.

The cost of option 3 is higher, but the cost of making that change is only ever going to go up. This seems to me like a "best time to plant a tree" type situation. Personally, when I make a change around postcard it's because I'm changing the data. Since that means changing both sides of the communication, there isn't actually any cost to a wire protocol change. On the other hand I don't think I've ever sent a char with postcard, so the char issue doesn't actually seem like that much of an issue.

jamesmunns commented 10 months ago

Yeah, there is IMO so little urgency for a breaking wire change, I almost want to skip it out of principle.

Personally, when I make a change around postcard it's because I'm changing the data.

I'm a little less convinced of this: if people have devices in the field, and they want to update their host and SOME devices, I don't want them to be worried about compat issues, and have to manually audit that they never use char.

CBJamo commented 10 months ago

I don't disagree with anything there.

For more context, currently I only use postcard to communicate between a linux host and a 2040 on the same board. If I'm deploying an update to the micro, I have to send it through the linux host, and I'll always be sending a new binary for the linux side anyway.

bsodmike commented 9 months ago

I'd vote for Option 2 and due to a reliance on postcard in channel-bridge v0.8.0 I'm blocked in upgrading one of my projects to rust 1.75...

How far away do you think we are from Postcard 2.0? months or...?

jamesmunns commented 9 months ago

Hi @bsodmike, the current answer is "at some point when I have time".

si14 commented 6 months ago

Adding as a bit of a wishlist item: I'd love to be able to do CRC+COBS+magic number header simpler. Right now I'm just using a copypasted version of CobsAccumulator with necessary changes, but it's not ideal.

Edit: that'd also make #135 a bit less of an issue because CRC would catch the corruption before serde picks it up.

jamesmunns commented 2 months ago

I put up a blog post calling for sponsors for postcard v2.0: https://onevariable.com/blog/postcard-2-sponsors/

bsodmike commented 1 month ago

Hi James, how goes the hunt for sponsors btw?

I'm happy to lend a hand, I'm still picking up the ropes but keen to learn etc. This is my most recent work but it's just a wrapper over Embassy https://github.com/bsodmike/rv8803-rs

Best, Mike