Where are API changes proposed for KotlinX IO? Is...

# io

[joseph_ivie]

Where are API changes proposed for KotlinX IO? Is there a roadmap somewhere? I want to know what parts of the API are considered more stable and which ones aren't, and what major plans exist to overhaul any of the systems.

[Filipp Zhinkin]

Hey! The most unstable (and unusable, if you'd ask me) part of the API is files and filesystem support. The current plan is to completely rewrite it (https://github.com/Kotlin/kotlinx-io/issues/241).

There are some tasks I want to solve before stabilizing the library, the kotlinx-io-stabilization milestone gives some idea on what's left there (https://github.com/Kotlin/kotlinx-io/milestone/5).

There's a chance that some niche APIs, like the so-called unsafe API, could be affected by those tasks, but at this moment there are no plans for major overhaul of anything besides the FS support.

[joseph_ivie]

Thank you! That makes a lot of sense to me. I'm finding the FileSystem/Path separation rather awkward to work with practically, so I'm glad that's not final.
Looking at the issues and commits, is this project on hold or low priority right now? I'm making a multiplatform library and I strongly prefer to make it depend on the most official library for its headers, but I'm a little concerned seeing the timestamps of commits and issues.

[Filipp Zhinkin]

There were a few tasks in other libraries that took my attention away from the kotlinx-io, but the library is not abandoned, and I'm planning to return to a more active development this Fall.

[joseph_ivie]

Oh good! Are the milestone issues that are listed there decided? In other words, if I go implement them, would it help or do the ideas themselves need additional investigation?

[Filipp Zhinkin]

They are not decided yet, unfortunately. I'll try to explicitly mark issues that only waits to be implemented with "up-for-grubs" or something. Partially, that's a reason why they were not implemented yet.

[joseph_ivie]

I kind of figured, but that's OK. Just seeing what I can do to help without getting in the way of the decision making.

[iseki]

So could you share the progress of this plan? Recently I found the currently implementation is nearly unusable on Windows platform so I open a PR to fix it. Of course there're also many enhancements and fix for the lacked important feature should be made as proposals.
But if you're planning totally rewrite whole implementation(personally I think it's a bit correct.) Maybe everyone in the community shouldn't pay attention on the current implementation.
Of course If here's the "new design" you'd better mention it on the issue or just close the issue. But I see many code in this part has a very old commit date.
So what's the current status of this plan?
Sorry for my bad English. @Filipp Zhinkin

[Filipp Zhinkin]

As of progress, we had a series of internal design meetings with the Libraries team. We considered a few options, which could be roughly categorized into “let’s make something similar to Java NIO”, “let’s make something resembling Okio”, and “and let’s make something in between, design-wise”. All options have some pros and cons, and we failed to choose a particular approach. Right now, I’m working on solving a selected set of real-life problems using each of these design approaches, to finally select one of them and start moving further

[Filipp Zhinkin]

In terms of contributions, I see a value in fixing issues with current implementation, as no matter which design approach will be chosen, the internal implementation will be based on the existing code.
When it comes to adding a new API, I always refer to https://github.com/Kotlin/kotlinx-io/issues/241 as a reason to postpone the work on new requests for now.

[iseki]

@Filipp Zhinkin How times flied. It's really a long time. I see the issue was created in 2023, ima wa 2025... Kotlin really need a well-featured IO library. I see the okio might solves some problem but it's not official and standard, right? Especially, Kotlin is a nominal typed language, I don't think it's a good ending one day we have to try{...}catch(okio.IOException|kotlinx.IOException|iseki.IOException)... .