-
Notifications
You must be signed in to change notification settings - Fork 63
Files and FileSystems support #241
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
Comments
Do you have plans to support non-UTF-8 encoding systems for file paths? This is crucial for some non-English systems, such as the GBK encoding used in Windows. Currently, OKIO does not support this(Native part), which makes it very inconvenient to use. |
@willflier that's a great question, thanks! Speaking of different encodings support in general, there were no plans to start working on it in the near future. However, I will definitely check what could be done with the fliename/path encoding on Windows. |
Yet another option to keep in mind is a support a family |
Hi, as mentioned in #163 (comment) I have also been working on a Kotlin file system API, and now I have a proposed API surface at https://github.com/zhanghai/MaterialFiles/tree/filesystem/app/src/main/java/me/zhanghai/kotlin/filesystem. Since this issue is also about a better and more powerful file system API, I hope my design and the rationale behind it might be helpful: The proposed API surface is designed with my experience/reading in:
It appears similar to the Java NIO File API, but with a number of (opinionated) choices:
Things like kdoc, |
I made some updates to the code above and finally got it published as a separate personal project https://github.com/zhanghai/filesystem-kt . You can check out its API reference here, e.g. Path. Notable changes include:
I should note again that this isn't any official Google effort despite that I'm an employee, but just a personal project from my experience working on zhanghai/MaterialFiles and released in the hope it may help with the API design for this. |
The ability to work with files and filesystems is one of the crucial features that a programming language could provide through its standard library. Even if an application is not built around reading and writing data from storage devices, it still may need access to a filesystem to, for example, read configuration files or write logs.
A constant stream of GitHub issues and feedback on
kotlinx-io
suggests a demand for fully-featured multiplatform files and filesystems API.The API exposed through
kotlinx.io.files
package was created to provide some partial file support quickly and is neither well-designed nor covers basic user needs. I'm proposing to review it, extend or redesign it if necessary.For the purposes of this proposal, file and filesystem-related features could be split into two coarse categories: basic and extended.
Basic features include the minimal necessary features required for working with files and filesystems, something one may expect from any FS-related API. Extended features include everything else.
Basic features
Below is the list of features to be considered as basic file and filesystem features.
Paths
FileSystem features
Files
FileSystems
Most of the features listed above are presented in the vast majority of modern filesystems. However, implementation details for some of them (like file metadata or permissions) vary significantly not only between different operating systems but also within filesystems on the same OS. The way these features will be supported should be decided during the design phase.
Extended features
Extended features include mainly OS- or FS-specific features, niche functionality, or something that is hard to implement reliably.
The list is non-exhaustive.
Paths
FileSystem features
FileSystems
Files
Nice to have features
Not fitting to either of two previous categories, but nice to have features:
java.nio.file.FileSystem
on JVM to reuse existing third-party filesystem implementations, like S3-FS.The plan
The overall plan is to review existing files and filesystem API, redesign it if needed, and then concentrate on supporting all the basic features.
The list of basic features is the subject of change, further subdivision and prioritization.
There are no particular plans regarding features considered extended, but the proposed design should be flexible enough to allow their support in the future.
The text was updated successfully, but these errors were encountered: