Reboot rsocket-kotlin as a multiplatform + Coroutines based project

[sdeleuze]

With the announcement of Coroutines Flow (see also preview status information and related open issue on their bugtracker), I think we have now all the required pieces to make rsocket-kotlin more than the kind of less maintained duplicate of the Java one that may be removed at some point.

Kotlin is becoming more and more a multiplatform language and I think after leveraging rsocket-transport-netty and rsocket-transport-okhttp (worth to notice that OkHttp plans to migrate to a Kotlin codebase) to provide the JVM implementation, it would be interesting to see if it is doable to provide a Kotlin/JS one. It is too early for a Kotlin/Native implementation but we could target that middle/long term.

Here is an overview of what could look like this multiplatform API.

interface RSocket : Availability, Closeable {
    suspend fun fireAndForget(payload: Payload)
    suspend fun requestResponse(payload: Payload): Payload
    fun requestStream(payload: Payload): Flow<Payload>
    fun requestChannel(payloads: Flow<Payload>): Flow<Payload>
    suspend fun metadataPush(payload: Payload)
}

I guess Payload could leverage Kotlin multiplatform I/O library.

I plan to work on that myself (with the help of others if some are interested to join) since that will allow me to validate various points of Flow API design including its Reactive-Streams interop. Also I do think this kind of approach would provide an interesting way to explore for multiplatform support that could ultimately allow RSocket to gain more traction.

[yschimke]

@sdeleuze JDK 8 isn't as big issue an for rsocket-java on Android anymore, so a differentiator for Kotlin seems like a big win. This seems like a good idea.

[mostroverkhov]

This is good initiative - I think we can replace this one once there is runnable code for some interactions (personally interested in streams and channels). Also wondering what runtime footprint will be if I want rxjava bindings for parity with rsocket-java. above interface seems reasonable - @sdeleuze do you have any additional code to share?

[sdeleuze]

I have not yet additional code since Flow preview has just been released and Kotlin multiplatform I/O library upcoming version will be significantly refactored.

I think I am going to start by using Coroutines and Flow as much as I can in APIs and see the impact on tests. Laziness and demand management are the 2 domains where I expect differences. Notice that Flow design is not frozen yet, so that could be an opportunity to send feedback to Kotlin team if needed.

[sdeleuze]

https://github.com/Kotlin/kotlinx-io is still under heavy refactoring, I am waiting a usable version to be able to move forward.

[whyoleg]

I've started moving this project to kotlin MPP with coroutines
Just for fun, and curiosity
https://github.com/whyoleg/rsocket-kotlin/tree/kotlin-mpp-coroutines-flow
I've started with removing dependencies on RxJava, and replacing it with kotlinx.coroutines
Then, I think it's a good choice to setup 2 transports, one for okHttp, which exists now, and new with Ktor client - it support multi-platform now with different engines
Then, will be the hardest part I think, replace netty with kotlinx.io and atomics with kotlinx.atomicfu
Until that moment it will support only jvm
Then, move all possible code to common and use if needed expect/actuals to support other platforms
I don't know, how much time it will take

[whyoleg]

Hi all, I have update on kotlin mpp rsocket
I've changed plans, and take as base - rsocket java implementation, as it is contains more implemented features. So, rsocket here is the new repository where I work on mpp kotlinization of rsocket
I've just finished replacing reactor with kotlinx.coroutines, it still have a lot of issues and big TODO list
As Flow has no concept of requestN, if someone has thoughts about how it will be better work with it, then just use request1 everywhere, pls tell me

[yschimke]

My suggestion would be to start with a thin wrapper based on top of the reactor. In reality much of the kotlin flow/coroutines world will not be pure kotlin code but bridge code to lower level existing java libraries.

[sdeleuze]

That would be indeed a good start.

[altavir]

I am a little bit involved with kotlinx-io. Sadly it won't be stable for some time. And currently it is focused on blocking io - coroutines will come later. So it makes sense not to wait for it. In fact, From current API, it seems that you do not need it. You just need to wrap nio calls with coroutines. The discussion could be done in kotlin slack (https://kotlinlang.slack.com/archives/CKCAAV8VB, http://kotli.in/slack for registration).

[miguelhrocha]

Hey @sdeleuze I would be interested in putting some efforts in booting this as a multiplaform project. How would we kickstart it?

[altavir]

Surprisingly, we had a discussion about that just yesterday. We are doing a research project with kotlin-multiplatform as a base and we decided that RSocket seems to be a best-fit protocol for the project. The lack of coroutine integration is sad, but we intend to try and one of the students is currently researching native integration. I won't be able to contribute a lot of time, but I am maintaining a public fork of kotlinx-io (https://bintray.com/mipt-npm/dev/kotlinx-io) and I can adjust its features to better suit the needs of rsocket. Kotlinx io does not currently support coroutines, but it is possible to add asynchronous wrappers in some places.

[whyoleg]

For those who are waiting, here is published preview version of MPP rsocket-kotlin from PR.
Feedback is very appreciated!

[yschimke]

Should develop be the main branch now?

[whyoleg]

Closed by #76