Re: [w3ctag/design-reviews] Review of NativeIO (#566)

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](https://github.com/fivedots/nativeio-explainer/issues/4), [#9](https://github.com/fivedots/nativeio-explainer/issues/9), and [#12](https://github.com/fivedots/nativeio-explainer/issues/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](https://web.dev/file-system-access/#accessing-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!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/566#issuecomment-736883333