Intent to Experiment: Native File System API
Marijn Kruisselbrink
Contact emails
m...@chromium.org, oyip...@chromium.org, natt...@chromium.org
Spec
http://wicg.github.io/native-file-system/
Algorithms and normative text in the spec are still TODO but will be fleshed out during the experiment period.
Summary
The new Native File System API enables developers to build powerful web apps that interop with native applications by allowing the web apps to interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more. After a user grants a web app access, this API allows web apps to read or save changes directly to files and folders on the user's device.
This API was formerly known as "Writable Files" (and the intent to implement was sent under that name).
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/U4rXcm5CE4Y/3XmVtoAPDwAJ
Goals for experimentation
The main goal is to gain some knowledge about how users interact with the UI surfaces provided by this API. We will be collecting various metrics to measure this, for example accept/deny rate for permission prompts, how often users revoke permissions, etc.
The other goal is to figure out if the API surface as implemented is sufficient to support the use cases we are prioritizing. For this we'll be relying on feedback from implementers.
Experimental timeline
M78: Experiment begins.
M80: Last milestone of the experiment.
M81: Planned general availability of the API.
We plan to make necessary changes to the API during the experiment, although further experiments might be needed as well. We are also planning new features (writable streams integration, serializability of handles) that won't be part of this origin trial in M78. Once we have implemented these we'll figure out the best way to ship those, either as part of this origin trial (maybe extending the trial by additional milestones), or via separate origin trials.
Any risks when the experiment finishes?
Without this API websites using it will have to go back to <input type=file> and downloading blob URLs to be able to read from and write to the native file system. While not ideal, that should still give websites access to any data just as well. Even with this API a website will have to re-prompt the user for access to data written using it when a user revisits their website, so this doesn't make things materially worse, at least for reading data.
Ongoing technical constraints
None
Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
All desktop platforms will be supported. Our initial origin trial will not support Android, but we will explore what to do about UI and implementation on Android in the future.
Link to entry on the feature dashboard
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVbPPLzLn%2B%3DEreBYXt-%2B3iEjKwkVq8NKNcaCxjipuq4Zbw%40mail.gmail.com.