https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
o

orangy

02/24/2019, 9:23 PM
working on mpp file system, yes
🎉 13
r

Ruckus

02/24/2019, 10:06 PM
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

orangy

02/24/2019, 10:22 PM
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

jw

02/25/2019, 3:21 AM
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

msink

02/25/2019, 5:11 AM
Reading resources, on Native from `binaryBlob`s
o

orangy

02/26/2019, 12:46 PM
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

msink

02/26/2019, 1:09 PM
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

orangy

02/26/2019, 1:46 PM
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

jw

02/26/2019, 1:51 PM
For zip I only mean as its own file system 👍
🆗 1
b

basher

02/26/2019, 5:03 PM
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

orangy

02/26/2019, 7:49 PM
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

jessewilson

03/21/2019, 2:56 PM
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

jw

03/21/2019, 3:04 PM
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

orangy

03/21/2019, 6:03 PM
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

jessewilson

03/21/2019, 10:56 PM
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

orangy

03/22/2019, 8:40 AM
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
4 Views