Hello! I've got weird but interesting for me question about ktor client library. Would be glad to hear developers team answers. Had you thought about giving some additional API besides coroutines one? If had but decided not to do it, then why? (I don't need different API, just want to understand your position in this question) Thank you! Looking forward for your answer.

Hey @Kamo Spertsyan, thanks for the question.

maybe a callback based api instead?

Yes, callback based one

No, I'm sorry. We don't have any plans about callback based API

Could you explain a bit your position please?

Sure. Ktor client is made in a way that you can replace any blocking client without much effort: you don't have to restructure lots of code with callbacks and keep the logic linear. In the same time it's backed by coroutines, it allows to make implementation asynchronous.

I'm exploring different libraries with asynchronous api, so I'm just interested in the way you design ktor library. Coroutines API is not a problem) One last question please, want to clarify if I've correctly understood library. Are users able to use ktor without using coroutines in their projects?

Sorry for hijacking the thread. But IMHO, there is too much benefit of using linear logic vs callbacks. But for some platforms (Kotlin/JS), the cost of linear logic is so high that would make me settle with a callback based API for my multiplatform projects

@Kamo Spertsyan, nope there is no way

But for some platforms (Kotlin/JS), the cost of linear logic is so high that would make me settle with a callback based API for my multiplatform projects

And you build your own proxy with callback api over the coroutine-based libraries like ktor, right?

@anton.bannykh @Kamo Spertsyan please get in touch to discuss this

And you build your own proxy with callback api over the coroutine-based libraries like ktor, right?

Not really, just have a pure callback based on common code, and have something like suspending await methods, which one can opt to use over the default suspending ones. So, ktor-client-core becomes purely callback based, not depending on coroutines at all, and have something like ktor-client-ktx wich depends on coroutines and has those methods. Makes it easy to write common code independent of coroutines and use it in optionally in platforms like kotlin/jvm or kotlin/native

@andylamax are you avoiding coroutine-based API due to increased code size, or performance considerations?

@anton.bannykh affirmative

@andylamax So both then? Could you share any numbers?

Let me work on the numbers, I will share them by the end of the day

@andylamax friendly ping 😃