Add AccessHandle proposal #310
Conversation
AccessHandle.md
Outdated
|
|
||
| Promise<undefined> truncate([EnforceRange] unsigned long long size); | ||
| Promise<unsigned long long> getSize(); | ||
| Promise<undefined> flush(); |
There was a problem hiding this comment.
iirc, in the NativeIO/Storage Foundation API these were all synchronous as well. Could you elaborate on what you learned that made you change the API shape in this newer proposal?
There was a problem hiding this comment.
I've added an explanation under "New data access surface", could you take a look and tell me if that resolves this comment?
|
|
||
| This proposal is focused only on additions to the [Origin Private File | ||
| System](https://wicg.github.io/file-system-access/#sandboxed-filesystem), and | ||
| doesn't currently consider changes to the rest of File System Access API or how |
There was a problem hiding this comment.
While I know you're focusing on the origin private use cases specifically for this proposal, I think it would be worthwhile to explore what parts of this API could be exposed on arbitrary file handles as well. I believe there are a number of use cases that could be addressed by adding a couple of options to the createAccessHandle methods to slightly tweak its behavior.
Straw-man proposal createAccessHandle({inPlace: true, locking: true}) would match what you've described here, and be only available for origin private files.
On the other hand inPlace: false could then work with the same API surface for arbitrary file handles. While that would of course duplicate some API surface from the existing createWritable method, being able to read what has been written before it is flushed/comitted seems useful, and if this new API will be built on top of some better seekable streams primitive that might be a benefit as well.
Not sure if a non-locking version for the origin private file system makes sense, or is desirable, but for arbitrary files I think it would be useful to be able to create both locking and non-locking access handles.
While all that can probably be added after the fact, we can't really change the defaults for such options easily, so while it might perhaps make sense to initially only support a "inPlace: true, locking: true" mode (and throw/reject for any other options), I don't think that should be the default flags if we actually want to pursue a more unified API.
There was a problem hiding this comment.
That's a good point, I agree.
I've added a "mode" parameter to createAccessHandle, and an open question describing why it's there and what other values it could have. Please take a look and let me know if this covers what you meant!
This PR adds the proposal document for AccessHandles. AccessHandles are a new proposed surface that allows us to support Storage Foundation API's use cases through the Origin Private File System.
Further details on the origins of this proposal, and alternatives considered, can be found in the following documents: Merging Storage Foundation API and the Origin Private File System, Recommendation for Augmented OPFS.
Preview | Diff