15:47 <AlexandrosLiarok> anyone has experience with using any no_std protobuf libraries?

15:47 <AlexandrosLiarok> it seems prost got some no_std support but I am not sure what that implies

15:48 <cbjamo[m]> I've used prost in no_std. I needed to patch bytes for that to be no_std. Prost is ok, but I wish I hadn't use protobufs in the first place.

15:49 <AlexandrosLiarok> yea, I need to use it to export presets to the desktop and have them be compatible across firmware updates

15:49 <AlexandrosLiarok> I am open to alternatives

15:51 <cbjamo[m]> I don't know if this is applicable to your use case. For ours we have a gateway between the mcus and the rest of the system (and the rest of the system wants protobufs). If I was doing it again I'd use postcard between the mcu and gateway, then convert to the protobufs on the gateway.

15:53 <cbjamo[m]> This is the issue that requires the bytes patch: https://github.com/tokio-rs/bytes/issues/461 It may or may not apply to you, we're using the 2040, which is an M0.

15:54 <AlexandrosLiarok> not applicable unfortunately, I directly need to export to end users through midi.

15:54 <AlexandrosLiarok> and these presets may persist and be re-loaded across different versions :(

15:54 <cbjamo[m]> And here's my fork, which is really just a rebase (as of several months ago) of taiki-e's work: https://github.com/CBJamo/bytes/tree/cfg_target_has_atomic_update

15:55 <cbjamo[m]> Yeah, if you're locked into protobufs prost is a good library that's got a nice api.

15:55 <AlexandrosLiarok> there are some alternatives like femptopb

15:56 <AlexandrosLiarok> s/femptopb/femtopb/

15:56 <cbjamo[m]> What's your target mcu?

15:56 <AlexandrosLiarok> but it seems those don't provide streaming APIs which is annoying when full buffers are 6kb+

15:57 <AlexandrosLiarok> stm32h7

15:57 <cbjamo[m]> Ok, then you won't hit that issue, prost should just work out of the box.

15:58 <cbjamo[m]> I may have been unclear before, I like prost, I'd rather just never have to use protobufs.

15:59 <AlexandrosLiarok> yea I don't love it either.

15:59 <AlexandrosLiarok> Ideally I would use postcard but I need the forwards/backwards compatibility thing.

16:00 <cbjamo[m]> Take a look at postcard-rpc.

16:00 <JamesMunns[m]> (for context, postcard-rpc says "messages can never change, but you can add new kinds of messages"

16:00 <AlexandrosLiarok> to be clear, I need it just for the wire format

16:00 <JamesMunns[m]> * of messages")

16:00 <AlexandrosLiarok> I also save the wire format in memory :P

16:00 <JamesMunns[m]> this is sometimes useful, but not in all cases :)

16:01 <JamesMunns[m]> you could use the same trick postcard-rpc does:

16:01 <JamesMunns[m]> uniquely identify the "kind" of the message by hashing the schema

16:01 <JamesMunns[m]> but this means adding some bytes as a header to all messages.

16:01 <JamesMunns[m]> I did also see a new format, serde-brief, that I think is self describing and looks like it has good docs?

16:02 <JamesMunns[m]> I haven't tried it out yet

16:02 <AlexandrosLiarok> protobuf also has a small advantage in that it is a good format to describe your presets so that end users can build editors if they really want to.

16:02 <AlexandrosLiarok> since it is very cross-language

16:03 <JamesMunns[m]> yep, makes sense!

16:03 <JamesMunns[m]> Not here to talk you out of protobuf, it can be reasonable for all the complaints about it :)

16:03 <cbjamo[m]> Yeah, that's why our greater system demands the protbufs.

16:03 <cbjamo[m]> The other side is an ipad app, and they wanted protobufs.

16:06 <cbjamo[m]> JamesMunns[m]: This is interesting, thanks for pointing it out. A serde-first self describing format will be handy.

16:08 <AlexandrosLiarok> my main issue is detecting missing fields and adding non-fixed defaults which seems like it needs the per-field tagging protobuf approach.

16:08 <AlexandrosLiarok> and also ignoring unknown fields

16:09 <AlexandrosLiarok> (because presets can be shared across units of different versions)

16:18 <AlexandrosLiarok> serde brief seems cool, if used along with serde's default field tag

16:18 <AlexandrosLiarok> it would probably do the trick for me.

16:42 <AlexandrosLiarok> ideally I would also really like a kind of streaming serializer/deserializer

16:42 <AlexandrosLiarok> so that we don't need to keep a full maximum_size buffer at all times

16:43 <AlexandrosLiarok> it just needs to keep some state instead of doing it all in simple serialize/deserialize functions

18:00 <AlexandrosLiarok> .. which I guess is almost the same as using async write/reader traits.