Hi everyone ! For the past weeks I have been worki...

# feed

[Lionel Briand]

Hi everyone !
For the past weeks I have been working on a refresh of my CBOR codec in kotlin-multiplatform.
If you are in need of a replacement for JSON serialization or just want to check it out, there it is:
https://github.com/L-Briand/obor

It works like any kotlinx-serialization codec implementation, supports CBOR's major type 2 (byte string) encoding and tags :

@Serializable
data class Example(val foo: String, val bar: Int)

fun main() {
    val example = Example("Hello World !", 42)
    val encode = Cbor.encodeToHexString(example)
    assert(encode == "a263666f6f6d48656c6c6f20576f726c64202163626172182a")
    val decode = Cbor.decodeFromHexString<Example>(encode)
    assert(example == decode)
}

[Oleg Yukhnevich]

just curious: what is the reason to have one more CBOR codec?
There is an official experimental kotlinx-serialization-cbor which was updates with tags and other things not so long time ago? (not released yet, https://github.com/Kotlin/kotlinx.serialization/pull/2412)

[Lionel Briand]

This project was started when the kotlin-serialization was in beta. I didn't want to let it rot and wanted to finish it. It's also a fun challenge to learn and understand the api and limitations of the kotlinx-serialization tool. All in all it was a great experience for me.

[Bernd Prünster]

I think it would make sense to point out the differences between your work and the experimental CBOR-support baked into kotlinx-serialization. While the latest feature drop finally provides definite length support, tags and labels, it still does not sort properties, for example. so working with COSE requires manual sorting of members when defining classes. I'm sure there's a thing or two that differentiates both projects feature-wise (or maybe performance-wise).

[Lionel Briand]

@Bernd Prünster I've made sure to thoroughly test every feature the parser execute. I wasn't aiming at speed, COSE support or tagged object specified in the RFC for this release. I think there are ways to optimise the parser. Mainly annotations which are checked constantly. I've also put up a quick benchmark with the 1.7.2-RC release in the branch benchmark and it seems the one in 1.7.2-RC is faster.

[Bernd Prünster]

Thanks, that is very helpful! Is yours faster than the current release of kotlinx-serialization or the current dev branch?

[Lionel Briand]

No, the benchmark is revealing that the parser in dev branch is faster. I don't know why, I've just tested a basic benchmark case. Since you were asking, I thought of informing you. If you want I'll also inform you if i find further optimisations.

[Bernd Prünster]

upstream better damn well be fast, because Leonid was very adamant, that he won't be accepting a slowdown, just because new fancy features are introduced, so I spent quite some iterations analyzing and ironing out performance issues. 😉

I'll mos def be peeking through your code though, as it is always interesting to see multiple ways of solving the same problem. However, since we absolutely require COSE compliance, AND upstream is faster, your library not a contender for our use cases.