its great but the only thing that sucks about this is the serialization its pretty clear that state of the art approach is to not do any serialization, just wrap a buffer with something that can randomly access fields like SBE, capnproto, flatbuffers... but this is fine for majority, i just don't see why not have the best of the best.
I think you misunderstood. SBE, capnproto and flatbuffers are all serializations. So it is the same interface as JSON, but different implementations. The difference lies in the efficiency. In the call he mentioned that CBOR and protobuf are already supported (which is also very efficient). So krpc is separated from the concrete serialisation implementation :)
@@shadowpenguin3482 oh thats nice, i thought its hardcoded to use their own kotlin serialization thing they did a while ago... Regarding the libs mentioned no they do not do any serialization, they format data in binary form and store it in buffer, so when you get data over network into buffer you are literally ready to interact with that message, even mutate in place, you are not reading the buffer into new object and populating any fields. Similarly when you want to send the message its entire serialized form is ready in the buffer, no actual serialization or deserialization happens. Most applications have highest overhead from serializatios, with those you completely avoid that overhead.
@@shadowpenguin3482 oh i didnt see that serialization is independent, i thought they just use their own serialization which i remember was actually creating objects... i'll check what is the interfce, i find that often its not possible to integrate some of these zero garbage/zero serialization libs
@@shadowpenguin3482 so i was right, in order for you to implement a serializer for something like SBE/capnp/flatb you need much more controll over buffers and how they are managed, their interfaces forces you to return an object after reading the buffer, meaning you are done with the buffer once you return it, so you cant just do the wrap over buffer segment and return the flyweight... and thatas why you cant do it... as i said that's the only thing that sucks about this RPC, but its ok for the majority. UPDATE : i believe with this interface (SerialFormat) you could maintain a pool of buffers and pay the cost of buffer copy which is still much cheaper than any work converting binary into object... but yes you cannot take full advantage of zero copy and zero serialization... Still super useful library that makes perfect sense to have in kotlin, kudos to JB
![[VDZ22] 9 Java Patterns that Kotlin made obsolete by Sebastian Brunner](/img/n.gif)
This is awesome and so easy! Wow 😃
its great but the only thing that sucks about this is the serialization
its pretty clear that state of the art approach is to not do any serialization, just wrap a buffer with something that can randomly access fields
like SBE, capnproto, flatbuffers... but this is fine for majority, i just don't see why not have the best of the best.
I think you misunderstood. SBE, capnproto and flatbuffers are all serializations. So it is the same interface as JSON, but different implementations. The difference lies in the efficiency.
In the call he mentioned that CBOR and protobuf are already supported (which is also very efficient). So krpc is separated from the concrete serialisation implementation :)
@@shadowpenguin3482 oh thats nice, i thought its hardcoded to use their own kotlin serialization thing they did a while ago...
Regarding the libs mentioned no they do not do any serialization, they format data in binary form and store it in buffer, so when you get data over network into buffer you are literally ready to interact with that message, even mutate in place, you are not reading the buffer into new object and populating any fields. Similarly when you want to send the message its entire serialized form is ready in the buffer, no actual serialization or deserialization happens.
Most applications have highest overhead from serializatios, with those you completely avoid that overhead.
@@shadowpenguin3482 oh i didnt see that serialization is independent, i thought they just use their own serialization which i remember was actually creating objects...
i'll check what is the interfce, i find that often its not possible to integrate some of these zero garbage/zero serialization libs
@@shadowpenguin3482 so i was right, in order for you to implement a serializer for something like SBE/capnp/flatb you need much more controll over buffers and how they are managed, their interfaces forces you to return an object after reading the buffer, meaning you are done with the buffer once you return it, so you cant just do the wrap over buffer segment and return the flyweight... and thatas why you cant do it...
as i said that's the only thing that sucks about this RPC, but its ok for the majority.
UPDATE : i believe with this interface (SerialFormat) you could maintain a pool of buffers and pay the cost of buffer copy which is still much cheaper than any work converting binary into object... but yes you cannot take full advantage of zero copy and zero serialization...
Still super useful library that makes perfect sense to have in kotlin, kudos to JB
@@krellinthere are already protobuf implementations of the Kotlin Serialization library