Hi @fivedots - thanks for this. One initial question: is there any discussion going on with other implementers? Has there been any feedback or interest?

Also, you state that this helps with "much-requested use-cases for the web, such as implementing performant databases and gracefully managing large temporary files." I'm wondering if there are some bugs you can link to?

Taking a look at this again - one thing that occurs to us is that the name itself is a little confusing (and alarming). If it's origin-bound then maybe something like "origin bound virtual filesystem" would be more accurate? The name should be more descriptive so that web developers understand what this is and can make a reasonable decision about how to use it, compared to other APIs. Also "I/O" could cover a lot of bases - e.g. webUSB, webserial, ... but what we are talking about here is filesystem primitives...

How much does this API differ from the one provided by File System Access? And when it differs substantially then why?

Also @fivedots @rstz - can you get back to us on the previous question regarding implementer interest?

We discussed this in today's call. Some questions we had based on our understanding of the explainer:

1. Given that the characteristic of what this provides is a "file" (quotes due to it being a quasi-file in a virtual filesystem land), how can one share this "file" or a set of "file"s to another origin? This feels like a useful feature that we are unsure how it would be implemented.
2. How can these files be accessed from the OS? I suppose the answer is "you don't" - but given that everything doesn't happen on the web this seems like a missing feature.
3. How does this API relate to storage buckets?
4. Should there be an "ephemeral" mode for these handles? Curious about what your thoughts on with regards to immutability as well.

These are questions we had from the first skim - we'll look into this in a bit more depth in a separate breakout later.

Additionally, beyond WCIG where do you see this API being worked on?

I’ll try to reply to everything that has come up:

@torgo

• Re: Other implementers, we’ve received feedback from people working on Firefox and Safari in the issues of the explainer, in particular #4, #9, and #12 and informally at TPAC. That being said, we haven’t yet met or discussed next steps.

• Re: Bugs showing requested use cases, I don’t have publicly linked bugs at hand. The project was started before I joined, so I’m asking the people involved, I’ll update this issue once I have links to share. We have received direct positive feedback from partners, saying that NativeIO unblocked critical parts of their applications.

• Re: Naming, we agree. We’ve been meaning to change the name soon, the current candidates are Direct Access Storage API (to highlight the performance and direct random access of the allowed by the API), and Storage Foundation API (to highlight the main use cases, where the API acts as a low level backend for more sophisticated libraries e.g. SQLite or a bespoke cache).

• Re: Beyond WICG, we were thinking that it should be worked on WebAppsWG

@kenchris

• Re: Similarities with File System Access API, we differ on goals and surface, although we’ve had some conversations on possibly merging some of the functionality offered by the Origin Private File System and NativeIO. From my understanding, File System Access API was added to allow more powerful access to files stored in the client, with the Origin Private File System acting as helper for testing and allowing the writing of data before prompting for permission. NativeIO acts as a more traditional storage API, with data being bound to the origin and not necessarily accessible to applications in the host. The difference in interface (like File System Access API relying on Streams, while NativeIO using buffers) and assurances (like File System Access API requiring SafeBrowsing checks and creating file copies before writing to them) are usually in the service of performance and genericity. We are currently benchmarking and prototyping to see if it’s possible to merge parts of the APIs, with the main risk being that trying to cover many diverse needs, we won’t meet the requirements that make NativeIO useful.

@cynthia

1. We hadn’t considered sharing files between origins, it hasn’t come up in our dev trial yet. I agree it would be interesting, I’ll look into what changes would have to be made and update this issue.

2. Indeed, since we see NativeIO purely as a storage API, we haven’t added ways to interact with the OS. I think that may be covered by the File System Access API, so detailing the interaction between the two APIs might be useful. Generally exploring and documenting the interaction between NativeIO and other storage APIs was on our list, so we’ll eventually add it to the explainer.

3. The proposals are not directly related, but we expect that NativeIO would support buckets when they ship. It would probably mean that developers could specify to which bucket a file belongs to. We also talked about relying on buckets to mark files as temporary or ephemeral, but we haven’t really explored much of that.

4. Yes, “ephemeral” files have come up on partner feedback. We’ve internally discussed a proposal to add a flag to the open method that allows marking a file as “deleteOnClose”, which would work for new and existing files. I’ll update the explainer as soon as the details of the design are hammered out.
   As for immutability, we haven’t discussed it so far. I could see how it might be useful if files can be shared between origins, but right now an origin has to create all the data within NativeIO by themselves. Is there a particular use case that you have in mind?

Thank you all for the feedback and help!

Hi there, we will look at this again tomorrow in a breakout, so wondering if there has been made any progress since your last comment?

Hello, I only have a short update:

• After socializing our possible new names, we are leaning towards changing the name to Storage Foundation API
• We discussed sharing files across origins. Our main worry is that it will add a lot complexity (especially when managing file life cycle) and possibly constraints to the overall performance of the implementation. We haven't received feedback from devs requesting this sort of transferring, so we would need more context to figure out what the right cost/benefit balance is. We are keeping an ear out to understand how this could help!

One question - will flush() come with guarantees? What happens if your flush() doesn't finish and the tab is closed by the user? Does this warrant a weird special path like we have with Beacons? (Feels like if there is a guarantee then it should be normative in the spec, when that is written.)

I like the name "Storage Foundation API" as it will make it clearer to developers that this is not a file system API in the normal sense.

WebAppWG also sounds like the right venue.

One meta-level comment: in your ongoing work on this API and technology can you please consider the complexity of the developer experience. When we provide multiple, very similar and similarly-named APIs (which may have important differences) it makes the overall platform more difficult for developers to grok. Maybe consider an MDN article which lays out the differences for all the filesystem-like APIs?

We'll close this for now - looking forward to revisiting when there is a spec. (hopefully with the points we brought up above sorted out!) Thanks for bringing this to our attention!