Open bpavuk opened 6 months ago
I'm not sure if this library even has any code or dependencies that currently rules out its use on specific platforms. What exactly would we need to change?
Migrate to OkHttp v5.x and wait for them to bring other platforms' support, or choose the Ktor Client, rewrite all the networking code on another framework, and not wait for Square to bring multiplatform support for OkHttp. Both paths are time-consuming.
When previously rewriting the Streaming API, I already had the idea to go for ktor and with it go for suspend
functions, but that would have implications for users of the library that write in Java.
I don’t know how to write suspending Kotlin code that has good interoperability with Java code so I had put the idea on hold for the time being.
We need to adapt only the Java-exclusive bigbone-rx module to Kotlin coroutines, don't we?
@bpavuk Mhm, not entirely. At least from feedback we had gotten in the past, it seems like (some) people are also using the library called from “vanilla” Java without RxJava.
Having a Coroutines<>RxJava bridge would, for example, be possible via kotlinx-coroutines-rx3
and I have used that in apps. But I’m not sure how well—if at all—Coroutines can be used from a “pure” Java context.
That being said, I would still very much like to give ktor a try. Even if just for how much easier testing with it looks, especially for WebSockets which we use for the streaming portion of the Mastodon APIs.
Fast googling suggests we cannot call Coroutines from pure Java code. Maybe, we could publish the refactor as a separate artifact, like "BigboneX"? Sounds similar to Android -> AndroidX. You can still use the pure Android framework, but if you prefer the usability, then migrate to AndroidX.
I don’t see how we could keep that intact. We would then need to maintain both versions.
With ktor not being Coroutines-friendly but Coroutines-“based”, I don’t really see a way here. We would have to handle methods and functions as suspend
functions everywhere in the library. A Java layer could maybe expose them as synchronous by using them in a blocking fashion but I don’t really like that idea.
We’d likely have to think about how to move forward here and how we want to structure BigBone anyway. Do we want to keep on supporting pure Java? Do we want to introduce different modules to the library where users could, for example, use only our types but do the calls themselves, and then have the API calls as easy-to-call methods like we currently provide them, but in a separate module you could add a dependency for?
Either way, we’ll have to talk about it if we want to move forward with either KMP support or even just Coroutines.
Kotlin Multiplatform is slowly rising, many major libraries are either migrating or already support KMP. Google announced their official support of KMP, by the way. I know that there is a Mastodonk library, but the last commit was like 10 months ago