Relation between core and krpc projects

[Kadeluxe]

Hi. I'm in need of RPC between two Kotlin apps and this library was just in time to catch my attention.

I understand it's WIP.

I've read through available docs and the source and while I understand there is an almost ready to use implementation (kRPC) I would like to write my own implementation to account for my specific needs.

Question is, why kotlinx-rpc-core contains code related to kRPC? For example, RPCTransport interface even mentions kRPC directly in the comment:

An abstraction of transport capabilities for KRPCClient and KRPCServer.

Same for others such as RPCConfig and the whole kotlinx.rpc.internal package.
It confuses me a bit because on the one hand core package contains bare minimum to write an own implementation and on the other hand it contains lots of code which looks like it belongs to the kRPC which have its own projects.
I understand that kotlinx.rpc.internal package is not my business but I'm still curious.
Is this going to be used for more protocol implementations?

And realistically, if I want to write my custom implementation, do I need to use such things as RPCTransport or RPCConfig at all? It looks like they are not used in the core.
That's why I'm asking. Ultimately, the core package looks like it's "opinionated" towards kRPC by design. Am I right?

[Mr3zee]

Hi! First of all thank you for your interest in the library!

Second, you are right to see a problem here. Reasons are rather historical, and we plan to make a proper separation. It will come in some of the next minor releases, as it is a breaking change.

You don't need to use anything kRPC specific

[Kadeluxe]

Alright, thank you for clarifying, it makes sense now ☺️