RFC: Thoughts on Postcard 2.0?

[jamesmunns]

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 [postcard 2.0] - Revisit char encoding #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:

• Rename feature use-std to just std #124
• #118 Add support for latest embedded-io #123
• tinyvec #126
• Decide how to deal with heapless-v0.8 #121
• Consider removing O type parameter of serialize_with_flavor #103

[CBJamo]

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]

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]

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]

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]

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

[si14]

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.