https://kotlinlang.org logo
Join Slack
Powered by
working on mpp file system, yes
# multiplatform
o
working on mpp file system, yes
šŸŽ‰ 13
r
Will this include abstractions for things like zip file systems and virtual file systems (or at least the plumbing to implement them), or are they going to be more focused on actual file systems?
o
First step is to implement local file systems native to respective platforms. But weā€™re trying to accomodate for a pluggable design, yes.
šŸ‘Œ 1
Btw, use cases would be helpful, as usual šŸ™‚
j
In-memory for tests. Zip for reading/writing zips as if they're just normal folders preventing the need to special case them.
šŸ‘ 3
m
Reading resources, on Native from `binaryBlob`s
o
In-memory for tests
šŸ‘
Zip for reading/writing zips as if theyā€™re just normal folders preventing the need to special case them
Thatā€™s something Iā€™m not sure about. It requires some special and non-trivial handling of paths, like if I have 
/foo/bar/baz.zip!/a/b/c.txt
and then nested zips within zips, etc, etc. I donā€™t think we will have it in some first version. But ZipFS to open a zip file as a separate 
FileSystem
instance and working with it like with an isolated FS will be there.
Reading resources, on Native from `binaryBlob`s
Do you mean specially crafted resource files, like in games (e.g. WAD)?
m
Do you mean specially crafted resource files, like in games (e.g. WAD)
No, I mean on JVM - resources from jar, on Native something similar, readonly in-memory filesystem compiled and linked to executable file as map (resname : String -> resvalue: CValues)
o
I think resources in Native were not yet designed (@ilya.matveev). They are processed properly into 
processedResources
folder, but not placed into executable. You can zip this folder and use ZipFS to access data.
But yes, as a use case it is clear
j
For zip I only mean as its own file system šŸ‘
šŸ†— 1
b
In (my idea of the) ideal chronological order of fs path related features: 1. Path object that allows constructing paths to files that works in native and JVM 2. Ability to test if file exists in native/JVM 3. Ability to read/write data
1. would allow us to communicate with the host app about files 2. would allow us to understand current fs state of a file and build common logic around that 3. would allow us to build logic (more easily) around the data itself
o
Itā€™s all implemented already. Whatā€™s missing before initial 0.1 publish is working with file attributes (exists, isDirectory, isFile already supported, but not very efficient, doing stat on every access)
Here is something for multiplatform files. Of course, no API stability, no binary compatibility, nothing. We even didnā€™t have a proper API design session šŸ™‚ https://bintray.com/beta/#/orangy/maven/kotlinx-files/0.1.0-dev-26 GitHub: https://github.com/orangy/kotlinx-files
šŸŽ‰ 2
šŸ“ 2
j
Please reconsider having the Path know its FileSystem. It means paths cannot be value objects, and not being a value object wrecks many useful things
For example, testing is more difficult because if you want to test say, what happens when a file write fails, you cannot use the default filesystem anywhere
And in my experience it's quite difficult to constrain where the Path instances come from, even if you can control where the FileSystem instances come from
You canā€™t decode JSON or YAML directly to Path instances
You can't accept Path arguments from the command line
Basically all these things end up inevitably getting bound to the default FileSystem and you lose the utility of having fake file systems for testing
j
One case this has bitten me (with nio) is when you have a parent and child Path on FileSystem A which you relativize into a new Path. Then, you use that relative Path to take a base Path on FileSystem B to create a new child. With nio this is an invalid operation because you cannot use Paths across FileSystems. You are forced to 
toString()
the relative Path from the FileSystem A and resolve a child on the FileSystem B using the string form. Happens when mounting zip/jar/aars as FileSystems all the time.
šŸ‘ 1
o
Yep, I was thinking about this and Iā€™d make a universal path class, but I donā€™t yet know how to solve a couple of issues. First is that convenience methods cannot be implemented on 
Path
, such as 
myFile.openInput()
, and user will have to pass around 
FileSystem
instance around. Of course, convenience API could use default FS, but then most of code will be doing exactly this. Second, there are properties on the 
Path
that depend on the File System, such as 
\
or 
/
, allowed characters, etc. This is lesser problem, implementation could accept both separators, but then how to implement 
toString()
? Should it be 
toString(fs)
? I donā€™t say itā€™s impossible to solve this, or prove it is not solvable, I just didnā€™t give it enough thought yet. I did whatā€™s easiest to have it working somehow.
One idea I had but didnā€™t explore yet, is to have two types: 
Path
and 
File
, so that 
Path
is just that, a slash-separated string, and 
File
is a pointer into a file system.
j
For convenient APIs to open a stream, 
FileSystem.SYSTEM.open(path)
isnā€™t short but it's very straightforward
For directory separators, you get a long way by treating paths as opaque strings, just as posix does
o
If you want to work with whatever FS is given by external code (mock in tests, system, or zip), you need to pass 
FileSystem
instance around. This is a major inconvenience. Instead of having a function like 
fun loadData(path: Path)
or even 
fun Path.loadData()
you will have to have 
fun Path.loadData(fs: FileSystem)
and pass these two parameters all they way down to the code that opens a stream. Also, working with nullable paths becomes a pain.
Another approach could be to treat absolute paths as rooted in FS, relative paths as FS-free, and have a special ā€œpseudo-absoluteā€ path that is relative to current working directory
Iā€™ve created #kotlinx-files to discuss it, welcome to join
šŸ‘ 1
12 Views
Open in Slack
PreviousNext
Powered by