Jeff Martin on Nostr: nprofile1q…y8u0g Yeah, if you can't guarantee that all parsers agree on which ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq63w7zdlg2u0prldz2t2xtxq49upayn497zq3swe4euww4alts4ss4y8u0g (nprofile…8u0g) Yeah, if you can't guarantee that all parsers agree on which duplicate keys to discard, I definitely see how that gets you into trouble.
But if you don't control all the parsers (probably because of a cross-platform requirement?), then kotlinx.serialization is the wrong tool for the job anyway. In that case, the actual wire format is basically an implementation detail of the serialization library (and compiler plugin), and therefore makes it a bad choice for this kind of application. Rust's serde crate has the same drawbacks.
This is why I went with protobufs for my wire formats. A schema-based serialization system has much better portability in a situation where you don't control all the parsers, since the schema and the wire formats are explicitly specified. And having encoders/decoders already implemented for several different languages is just icing on the cake.
But if you don't control all the parsers (probably because of a cross-platform requirement?), then kotlinx.serialization is the wrong tool for the job anyway. In that case, the actual wire format is basically an implementation detail of the serialization library (and compiler plugin), and therefore makes it a bad choice for this kind of application. Rust's serde crate has the same drawbacks.
This is why I went with protobufs for my wire formats. A schema-based serialization system has much better portability in a situation where you don't control all the parsers, since the schema and the wire formats are explicitly specified. And having encoders/decoders already implemented for several different languages is just icing on the cake.