Multiplatform support #3181
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 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. |
|
Excluding js, is it easier to implement on other platforms?Android,IOS,MacOS,Windows,Linux and so on. |
|
No
…On Sun, Sep 1, 2019, 1:55 AM mengrong.yang ***@***.***> 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
<#3181?email_source=notifications&email_token=AAAQIENG2P7XHYEGMV6PBTDQHNKOJA5CNFSM4IH26TZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5T3FTI#issuecomment-526889677>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAQIEM52EK3STXOINFJMLLQHNKOJANCNFSM4IH26TZQ>
.
|
|
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 |
|
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 <#3181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQIEOLUVANILFTEH33Z6DSK4ZF3ANCNFSM4IH26TZQ>.
|
|
@JakeWharton ksp is stable now |
|
Is the status the same here? Would OkHttp 5.0 change the equation at all? square/okhttp#6963 |
|
I don't think it changes all that much until there's a working client on multiple platforms that I can evaluate. And I'm concerned about mentions of not supporting JS such that I may have to remove OkHttp entirely from Retrofit's public API to accomplish multiplatform. |
|
Without relying on OkHttp, Ktor client seems like a good candidate |
|
Possibly, although it itself is merely a wrapper around actual HTTP clients like OkHttp. I would prefer OkHttp for obvious reasons, but I also want to make sure it's the right reasons. Currently we gain a lot from exposing it as public API and I'm not sure Ktor client has the same level of features because it's an abstraction over existing clients. For example, OkHttp's tagging allows us to expose details about the Retrofit method to OkHttp interceptors. This is a wildly powerful feature that is going to be very challenging to replicate in a multiplatform context both because of the problem of the multiplatform HTTP client but also the lack of reflection in multiplatform. |
|
Weirdly have used the Ktor client API in two projects since writing that comment and it is very, very painful. Maybe they fixed it up in 2.0, but the latest stable one is not pleasant and I would not want to build on top of it here. |
|
If it makes retrofit happen, we should work out how to try to make OkHttp JS happen. |
|
JS is my most used platform after JVM/Android. I almost never use native. If you don't make it happen I'll just ship an HTTP client abstraction similar to Retrofit 1 with end-to-end coroutines and it will be a little painful but work just fine. It's probably a wise design decision anyway because I also would love to support Java 11's built-in HTTP client, too. This makes multiplatform HTTP client configuration a separate concern from Retrofit's perspective. So if OkHttp chooses to not work on JS then you can only do common configuration on JVM/Android/native and that's fine from Retrofit's perspective. In this regard I like Ktor client's design. |
|
I did just recently come across a library that is multiplatform and inspired by Retrofit, called Ktorfit. Not sure if something similar could be done with respect to Retrofit, although that implementation is built on top of Ktor 2.0 and used KSP. |
|
For most people, the core of retrofit, which is the most popular feature, is that it makes the network layer implementation of the application declarative (describe the API by interface with methods and the help of annotations, that is really cool), although this is implemented through so I think it's time to move on. |
|
Excited to see that Retrofit 5.0.0-alpha4 added experimental JS and iOS support! That obviously doesn't address any of the reflection-based reasons that Retrofit isn't multiplatform-friendly, but I figured that this was relevant info for folks following or stumbling across this issue |
|
That's OkHttp, not Retrofit |
|
5 years after, what's the current thoughts about this one? |
We can use |
|
@JakeWharton No rush from our side, we just want to know whats the current status for multiplatform? |
|
Nonexistent |
OkHttp has dropped multiplatform support in 5.0.0-alpha.13. Given that information you can estimate chances for Retforit to get multiplatform support. |
|
Sort of. OkHttp started by trying to make its existing API multiplatform, and that wasn't going well. It is what was removed. Instead, the plan is to build a dedicated HTTP model in isolation that can be used by libraries like Coil or Retrofit. OkHttp will be one implementation of that model, but you could also use another. |
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
createmethod) as a necessary step, but what could be else?The text was updated successfully, but these errors were encountered: