-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Kotlinx.IO #212
Comments
At some point, I'd love to, but for now it's marked as "alpha" and "incubator" - doesn't look stable. Let's wait until it's at least beta? |
I haven't looked at kotlinx-io at all, but I strongly suspect (since it's in alpha) it doesn't support all of the features that we use... yet. |
I think it would be great to do something similar to what is done in kotlinx-serialization-json for okio and kotlin-io. They have a few abstractions like In this case, we would be able to create independent implementations for okio and kotlin-io (which can be marked as experimental) and people can choose what to use. |
I might be missing something but from my point of view the only things used right now from okio are:
From a first look, all of that can be found in kotlinx-io (with some different naming but it can be found) |
I do like this idea, but I think it makes sense for Kaml to do this, not SnakeKMP. Maybe SnakeKMP does need to abstract all of the IO stuff and rely on Kaml converting Okio/kotlinx-io types into the abstractions.
My suspicion could be wrong :) But from looking at the kotlinx-io PR for Kaml, it requires using InternalIoApi. We definitely need to avoid that. |
It looks like a mistake in PR. The
This idea sounds great. Creating an abstractions from a particular IO library will give more flexibility for end users. And this definitely should be done as the first step to support different IO libraries. |
Don't get me wrong, I'm not disagreeing: better support for Okio and kotlinx-io would certainly be a good thing, and I'm totally on board. However, I see SnakeKMP is the supporting, utility focused backend, and Kaml is the friendly, user facing frontend. SnakeKMP should focus on performance and correctness, while Kaml should focus on usability. (Ideally SnakeKMP would have zero dependencies, but the Kotlin multiplatform stdlib doesn't have enough IO stuff yet.) So, when it comes to SnakeKMP I think the best strategy is to pick the IO library that works best for performance and integration with Kaml. Currently I think Okio is best suited to support that, since it's older and has more support. But definitely when kotlinx-io becomes stable it makes sense to use it instead, because it's official. And then it's up to Kaml to provide Okio/kotlinx-io/java.io/whatever-else integrations. At least, that's how I see it! |
I think I got your point and I agree with you, especially with
Maybe it is worth parking this question until Kotlin has standardized IO interfaces... But if SnakeKMP had an extension point (like kotlinx-serizalization-json does), it would allow to do something about the above right now (for Kaml or any other library/application). |
https://github.com/Kotlin/kotlinx-io
The text was updated successfully, but these errors were encountered: