Separation of kotlinx-rpc runtime and kRPC protocol implementation

[whyoleg]

AFAIK from the sources, on current moment kotlinx-rpc runtime consists of:

• kotlinx.rpc basic types (like RPC, RPCClient, RPCServer, RPCCall, RPCField) used by compiler plugin to generate support code and can be used to implement transport for rpc
• kRPC protocol implementation with client and server modules specifically for them with RPCTransport and RPCConfig used mostly for them and not really required for implementation via other protocols (RSocket, gRPC). runtime-serialization and runtime-logging are also mostly needed for kRPC.
• transport-ktor which binds kRPC to ktor for both client and server

Are there any plans on somehow better borders between kotlinx.rpc API and kRPC implementation? On current moment it's a little confusing to understand, which types to use to implement custom protocols.

If I may, this is how I see the high-level structure here per modules:

• kotlinx-rpc-core - just core APIs used both by kRPC and other protocols (it's mostly current runtime module, but without RPCTransport and RPCConfig and internal classes, which implements kRPC)
• kotlinx-rpc-krpc (or kotlinx-rpc-krpc-shared/kotlinx-rpc-krpc-internal/etc.),
  kotlinx-rpc-krpc-client,
  kotlinx-rpc-krpc-server - (yeah, naming is hard, but still) kRPC implementation with RPCTransport and RPCConfig (probably renamed to KRPC*), internal classes from runtime module and APIs for client and server to bind kRPC implementation to some transport (f.e ktor). serialization and logging modules most likely should go in this category.
• transport-ktor modules probably just renamed to mention that they are krpc specific.
• in future then the project could have kotlinx-rpc-grpc - which AFAIU should not depend on kRPC at all - but may be I'm missing something here :)

Would be nice to hear what you think, as may be I don't know about some future plans/ideas.

P.S. I'm very glad to see kotlinx-rpc and I'm willing to try to implement rsocket-kotlin integration!

[Mr3zee]

Hey @whyoleg ! You are totally right, the namings are misleading right now and are the legacy from the previous internal structure. Basically, you got all of the details right, and gRPC won't be dependent of kRPC The issue, as you mentioned, is that kotlinx-rpc-krpc- prefix is meh to put it shortly. We will come up with a better structure and put it into 0.2.0 release

[Mr3zee]

As per rsocket integration - this is what we would be very interested in. And firstly in terms of how easy it is to work this existing APIs, what should be added/improved. Please, feel free to contact me anytime for any questions and suggestions

[whyoleg]

Thanks for the fast feedback!

The issue, as you mentioned, is that kotlinx-rpc-krpc- prefix is meh to put it shortly.

Yeah, several other options to consider, while we are here (order is irrelevant):

• use just kotlinx-krpc-* without rpc in the middle (which is still kotlinx-kotlin-rpc but a little bit nicer)
• extract krpc to a separate project (similar to ktor/exposed), package could be krpc/io.krpc/org.jetbrains.krpc and leave kotlinx-rpc as compiler plugin + small runtime. Overall, while kPRC is KMP specific, it's still looks for me like a separate project/product
• come up with another name (but I really like kRPC)

We will come up with a better structure and put it into 0.2.0 release

Looking forward to it!

As per rsocket integration - this is what we would be very interested in. And firstly in terms of how easy it is to work this existing APIs, what should be added/improved.

Yeah, I'm planning to create a PoC in coming weeks...

[Mr3zee]

Hi! Some updates regarding this issue

These current modules:

kotlinx-rpc-runtime
kotlinx-rpc-runtime-api
kotlinx-rpc-runtime-client
kotlinx-rpc-runtime-server
kotlinx-rpc-runtime-logging
kotlinx-rpc-runtime-test
kotlinx-rpc-runtime-serialization
kotlinx-rpc-runtime-serialization-cbor
kotlinx-rpc-runtime-serialization-protobuf
kotlinx-rpc-transport-ktor
kotlinx-rpc-transport-ktor-client
kotlinx-rpc-transport-ktor-server

Will be renamed to these (order preserved):

kotlinx-rpc-core
kotlinx-rpc-core-api
kotlinx-rpc-krpc-client
kotlinx-rpc-krpc-server
kotlinx-rpc-krpc-logging
kotlinx-rpc-krpc-test
kotlinx-rpc-krpc-serialization
kotlinx-rpc-krpc-serialization-cbor
kotlinx-rpc-krpc-serialization-protobuf
kotlinx-rpc-krpc-ktor-core
kotlinx-rpc-krpc-ktor-client
kotlinx-rpc-krpc-ktor-server

Other modules will stay as is for now If you have any issues with it - please express them here