[w3ctag/design-reviews] Native File System API (#390)

こんにちはTAG！

I'm requesting a TAG review of:

  - Name: Native File System
  - Specification URL: https://wicg.github.io/native-file-system/ 
  - Explainer, Requirements Doc, or Example code: https://github.com/WICG/native-file-system/blob/master/EXPLAINER.md

  - GitHub issues (if you prefer feedback filed there): https://github.com/wicg/native-file-system/issues/

  - Tests: https://github.com/web-platform-tests/wpt/tree/master/native-file-system

  - Primary contacts: @mkruisselbrink, @oyiptong

Further details:

  - Relevant time constraints or deadlines: We're planning to ship parts of this in an [Origin Trial](https://github.com/GoogleChrome/OriginTrials) in Chrome in M77, which means we'd need to have something ready by late July. We don't expect to have everything implemented by then, or even have figured out what the entire API surface should be. [This document](https://docs.google.com/document/d/11rcS0FdwM8w-s2esacEQxFfp3g2AAI9uD7drH8ARKPA/edit#) tracks differences between what is spec'ed end what we have or are planning to initially implement.
  - [x] I have read and filled out the [Self-Review Questionnare on Security and Privacy](https://www.w3.org/TR/security-privacy-questionnaire/). The [assessment is here](https://github.com/WICG/native-file-system/blob/master/security-privacy-questionnaire.md).
  - [x] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/design-principles/)
  - The group where the work on this specification is: WICG
  - Links to major unresolved issues or opposition with this specification:
     * One big unresolved (as of filing this) issue is the best way to go about integrating with writable streams (https://github.com/WICG/native-file-system/issues/19 and https://github.com/WICG/native-file-system/pull/62).

You should also know that...

As mentioned above, we fully expect to be iterating on the best shape of this API for at least the duration of the origin trial (i.e. most of 2019). We have some idea of what we want the API to look like, and what use cases we want to support, but also expect to learn from the origin trial that perhaps we were wrong about what is needed for which use cases.

We'd prefer the TAG provide feedback as (please select one):

  - [x] open issues in our GitHub repo for each point of feedback
  - [ ] open a single issue in our GitHub repo for the entire review
  - [ ] leave review feedback as a comment in this issue and @-notify [github usernames]



-- 
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/390