String-based vs. Object-based file access

[atjn]

I think you made a mistake by basing access on text paths. I think a better way to handle this is via objects that represent a specific path. What if I want to access the test.txt file in the dir files/. I have to do string manipulation for that? I'd rather call DirHandle.getFile("test.txt") and get a FileHandle back that I can read/write to.

This is not just convenience, it is a common bug that string manipulation results in paths with double slashes, missing slashes, or one slash that is the wrong type (\ vs /), or countless other normalization issues. Abstracting this away is IMO a service to the developer and the end user.

Object-based systems also have better type safety and much better intellisense.

Another reason to go with objects, is that the new file system APIs that are being implemented in browsers are object-based. In my experience, it is easy to adapt objects to path APIs, but hard to adapt paths to object APIs, especially given that the browser APIs require user permissions to be attached to the objects.

Maybe the object-based APIs can be added on top of fsx, but that seems like unnecessary complexity to me.

[atjn]

This is a repost of: https://mastodon.online/@atjn/111734301732772549 :)

[nzakas]

Another reason to go with objects, is that the new file system APIs that are being implemented in browsers are object-based. In my experience, it is easy to adapt objects to path APIs, but hard to adapt paths to object APIs, especially given that the browser APIs require user permissions to be attached to the objects.

Can you give an example?

[nzakas]

Thanks, that's helpful. Overall I think OPFS is way too heavy-handed for most use cases and is really strictly designed to enable security between a browser and the local disk. There may be some learnings there, but I think my current approach is still the path I'll walk down.

[boneskull]

There are considerable benefits to the suggested idea in the browser, but when the underlying implementation (e.g., node:fs, libuv and the OS beneath it) doesn't support this paradigm, you won't get much bang for your implementation-buck.

That being said, it would be neat to have some sort of way to bring-your-own primitive. Certainly, the user-facing implementations (e.g., fsx-node) don't need to expose it (or if they did, not by default). It would be neat if the core API accepted paths of type T = string instead of just string. That way I could define a new instance with paths based on T; e.g., T is URL and now my instance only accepts URL paths.

(Also: the core API should probably support URL, shouldn't it? I'd expect all target platforms to support that at this point)

[boneskull]

Also: fsx is interesting to me not because of the cross-platform-ness of it, but the swappable Impls.

If I own an fsx instance, and I can provide an instance to my dependency, I can decide--at a high level, and with a considerable amount of granularity--what my dependency can do with it. That makes it desirable from a supply-chain security standpoint. I can choose to make e.g., fsx.write() a no-op for dependency foo, but leave it intact for bar. There's far more to it than that (e.g., if a dependency tries to create its own fsx instance, it should only ever receive what I've allowed it to), but it's a start.

Of course, those dependencies must accept my fsx instance in the first place 😄. Hence, #44.

[atjn]

Overall I think OPFS is way too heavy-handed for most use cases and is really strictly designed to enable security between a browser and the local disk. There may be some learnings there, but I think my current approach is still the path I'll walk down.

That's fair, I am interested in seeing what you can do with it :) I don't see why OPFS is too heavy-handed, it seems to support all use cases but with better DX and with better type safety. You make it sound like the security aspect is too limiting for anything but browsers, but in my experience, native applications are looking at the security benefits of web apps and are trying to implement similar safety designs as well because it shields against so many mistakes. I firmly believe that object-based is the future of file system API's.

[nzakas]

At some point I'll write up why I don't think OPFS is a good option outside of the browser, but for now, it's clear that we disagree and that's okay. 😄