Jeff Martin on Nostr: nprofile1q…y8u0g Oh, interesting. I didn't realize kotlinx.serialization could use ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq63w7zdlg2u0prldz2t2xtxq49upayn497zq3swe4euww4alts4ss4y8u0g (nprofile…8u0g) Oh, interesting. I didn't realize kotlinx.serialization could use different wire formats. Technically, Rust's serde can use different formats too, but the serialization library itself still leaves its own impression on things, which bothers me. Probably kotlinx.serialization does something similar?
It's probably a side-effect of using a data-type-centric serialization system, rather than something more uniform like a schema-based system. I'd still recommend a schema-based system for something like this, since the serialization libraries have to conform to the (cross-platform) schemas, rather than the serialization libraries getting leeway to do something totally different in each programming language. That way, you basically get the benefit of the test vectors in the serialization spec itself without having to re-create that in your app.
Weird that the kotlinx.serialization people claim to support the CBOR spec, but have no interest in actually being compliant. Maybe you just need to hope that there's another spec/library combo out there that works as advertized.
The limitation seems well-disclosed though. It didn't take me long to find this:
https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-cbor/kotlinx.serialization.cbor/-cbor/
In that case, kotlinx.serialization+CBOR probably isn't fit for purpose here and you're definitely better off using something else. But you already know that. =P
I've been having success with protobufs before. They're basically Boring Tech at this point. But feel free to roll your own if you have more specific needs.
It's probably a side-effect of using a data-type-centric serialization system, rather than something more uniform like a schema-based system. I'd still recommend a schema-based system for something like this, since the serialization libraries have to conform to the (cross-platform) schemas, rather than the serialization libraries getting leeway to do something totally different in each programming language. That way, you basically get the benefit of the test vectors in the serialization spec itself without having to re-create that in your app.
Weird that the kotlinx.serialization people claim to support the CBOR spec, but have no interest in actually being compliant. Maybe you just need to hope that there's another spec/library combo out there that works as advertized.
The limitation seems well-disclosed though. It didn't take me long to find this:
https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-cbor/kotlinx.serialization.cbor/-cbor/
In that case, kotlinx.serialization+CBOR probably isn't fit for purpose here and you're definitely better off using something else. But you already know that. =P
I've been having success with protobufs before. They're basically Boring Tech at this point. But feel free to roll your own if you have more specific needs.