Given that okio went multiplatform already, and okhttp is slowly going towards that direction, would it be possible for Retrofit to go multiplatform some day? I'm just curious what are the required steps for this, apart from the actual conversion to Kotlin (which is not planned yet, according to the issue I mentioned).
I would see moving from reflection-based annotation parsing (as I assume it's not working in native) to compile-time annotation processing + codegen of interfaces' implementations (instead of create method) as a necessary step, but what could be else?
romtsn
All 5 comments
No earlier than 2 years. More realistically probably 4 or 5 years.
To say Okio went multiplatform is true, but it lacks the facilities for even implementing OkHttp in multiplatform contexts (specifically, timeouts and deadlines). So we're really blocked on Okio finishing itself going multiplatform and exposing this behavior, likely through coroutines. Additionally, blocking IO simply doesn't work in places like JavaScript so it's not clear Okio is even ready to be utilized there. Essential functionality like the gzip and deflate support are absent on non-JVM platforms. That's the first blocker.
Next, OkHttp is now written in Kotlin but it's API is coupled to the JVM. Decoupling this will be a large effort and almost certainly require breaking the API. Not to mention the reimplementation on JS and native, or delegation to platform-specific equivalents in a way that provide consistent behavior. This can probably be done on native, but OkHttp doesn't seem the right layer of abstraction for adapting JS clients. That's the second blocker.
Finally, Retrofit relies on mechanisms which are not available on JS or native or do not have satisfying equivalents. Switching to code generation is not at all easy because of the behavior of converter factories and call adapter factories. This was evaluated 5-ish years ago and deemed infeasible or requiring too many trade-offs. That leaves reflection, which is possible, but blocked on Kotlin again. And it would also would likely mean taking a kotlin-reflect dependency on the JVM which is currently a complete non-starter.
Now Retrofit is a layer where abstraction over multiple HTTP clients could be done, and it probably could be done in about a year. But it would mean severely restricting the API where there weren't any converters or adapters so suspend fun was your only choice and kotlinx.serialization types, UByteArray, or String were the only supported return types (or Response<T> of those types). That might be something I would build, but it would be the opposite of Retrofit.
It's not that I'm opposed to this. I want this. It just doesn't seem feasible in the next few years as it requires significant work on our upstream dependencies first. I'll be pushing for, following, and in some cases contributing that work. But this is _definitely_ not something you should be holding your breath on.
JakeWharton
on 31 Jul 2019
Excluding js, is it easier to implement on other platforms?Android,IOS,MacOS,Windows,Linux and so on.
yangwuan55
on 1 Sep 2019
No
On Sun, Sep 1, 2019, 1:55 AM mengrong.yang notifications@github.com wrote:
Excluding js, is it easier to implement on other
platforms?Android,IOS,MacOS,Windows,Linux and so on.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/3181?email_source=notifications&email_token=AAAQIENG2P7XHYEGMV6PBTDQHNKOJA5CNFSM4IH26TZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5T3FTI#issuecomment-526889677,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQIEM52EK3STXOINFJMLLQHNKOJANCNFSM4IH26TZQ
.
JakeWharton
on 1 Sep 2019
Is this any more possible now then when this was posted a year ago?
At a glance OkHttp and Okio seem to be in the similar positions so I would guess not, but would be interesting to hear if there's any internal conversations amongst yourselves
CharlieTap
on 15 Oct 2020
No change.
Maybe with KSP eventually supporting multiplatform, but it's not super interesting to me right now to explore considering how experimental it is.
On Thu, Oct 15, 2020, at 1:52 PM, CharlieTap wrote:
Is this any more possible now then when this was posted a year ago?
At a glance OkHttp and Okio seem to be in the similar positions so I would guess not, but would be interesting to hear if there's any internal conversations amongst yourselves
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/square/retrofit/issues/3181#issuecomment-709490506, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQIEOLUVANILFTEH33Z6DSK4ZF3ANCNFSM4IH26TZQ.
JakeWharton
on 15 Oct 2020
Related issues
chriskessel
·
3Comments
jpshelley
·
4Comments
starktonys
·
3Comments
Hesamedin
·
3Comments
JerzyPuchalski
·
3Comments
Most helpful comment
No earlier than 2 years. More realistically probably 4 or 5 years.
To say Okio went multiplatform is true, but it lacks the facilities for even implementing OkHttp in multiplatform contexts (specifically, timeouts and deadlines). So we're really blocked on Okio finishing itself going multiplatform and exposing this behavior, likely through coroutines. Additionally, blocking IO simply doesn't work in places like JavaScript so it's not clear Okio is even ready to be utilized there. Essential functionality like the gzip and deflate support are absent on non-JVM platforms. That's the first blocker.
Next, OkHttp is now written in Kotlin but it's API is coupled to the JVM. Decoupling this will be a large effort and almost certainly require breaking the API. Not to mention the reimplementation on JS and native, or delegation to platform-specific equivalents in a way that provide consistent behavior. This can probably be done on native, but OkHttp doesn't seem the right layer of abstraction for adapting JS clients. That's the second blocker.
Finally, Retrofit relies on mechanisms which are not available on JS or native or do not have satisfying equivalents. Switching to code generation is not at all easy because of the behavior of converter factories and call adapter factories. This was evaluated 5-ish years ago and deemed infeasible or requiring too many trade-offs. That leaves reflection, which is possible, but blocked on Kotlin again. And it would also would likely mean taking a kotlin-reflect dependency on the JVM which is currently a complete non-starter.
Now Retrofit is a layer where abstraction over multiple HTTP clients could be done, and it probably could be done in about a year. But it would mean severely restricting the API where there weren't any converters or adapters so
suspend funwas your only choice andkotlinx.serializationtypes,UByteArray, orStringwere the only supported return types (orResponse<T>of those types). That might be something I would build, but it would be the opposite of Retrofit.It's not that I'm opposed to this. I want this. It just doesn't seem feasible in the next few years as it requires significant work on our upstream dependencies first. I'll be pushing for, following, and in some cases contributing that work. But this is _definitely_ not something you should be holding your breath on.