Intent to Prototype: FileSystemHandle.getCloudIdentifiers()
Alexander Hendrich
Hello blink-dev team,
For now, we are looking to prototype (and later launch) the new web API (FileSystemHandle.getCloudIdentifiers()) for ChromeOS only (with GoogleDrive and OneDrive as providers). Other platforms and providers will come later, but are not prioritized yet. The first CL just started the review process.
PTAL, thanks!
Contact emails
hend...@chromium.org / hend...@google.comMentor: asu...@chromium.org
Explainer
https://github.com/WICG/file-system-access/blob/main/proposals/CloudIdentifier.mdSpecification
NoneSummary
This proposal adds a new getCloudHandles() method to FileSystemHandle, which allows retrieval of cloud handles for a file/directory. A cloud handle consists of a vendor identifier (e.g. "drive.google.com") and a file identifier. With these, the web app can talk to the cloud storage provider through its APIs directly to retrieve/modify the file. This is useful for web apps to figure out if a file is already backed by cloud storage and allows for easier transfer across machines as just the identifier instead of the entire file contents needing to be transfered.
Blink component
Blink>Storage>FileSystemMotivation
Web apps interacting with files/directories via file system access web API can benefit from additional capabilities when they know whether a file/directory is synced via cloud storage and what ID the cloud storage provider is using for it. Use cases: * Remote file handling: If the file should be transferred to another machine, instead of uploading it from the device itself and syncing it back, we can simply pass the cloud identifier for the file/directory to the remote machine, which directly pulls it from the cloud storage provider and also syncs it back. * De-duplication for online document editors: For cloud-based online document editors (Google Docs or Microsoft Office 365 web), the document needs to be in cloud storage (Google Drive or Microsoft OneDrive) before it can be edited. With this API, the web app could detect that a given file is already in cloud storage and edit it directly instead of creating a new duplicate. * Drag & drop into Mail: When sharing a large file via mail, instead of actually transferring the file with the mail as attachment, the web-based mail clients could instead detect that the file is in cloud storage, request it to be shared via link and simply include the link in the mail.
Initial public proposal
https://github.com/WICG/file-system-access/blob/main/proposals/CloudIdentifier.mdTAG review
TAG review status
PendingRisks
Interoperability and Compatibility
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
Debuggability
Is this feature fully tested by web-platform-tests?
No. Testing this feature requires a cloud storage sync client (e.g. GoogleDrive / OneDrive), which is not possible to mock for WPT tests. The only test we can produce is test that the result for a local file is an empty list.Flag name
FileSystemAccessGetCloudIdentifiers (CL just started review)Requires code in //chrome?
TrueTracking bug
https://crbug.com/1443354Launch bug
https://launch.corp.google.com/launch/4234443/approver/14472Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5130687725699072Links to previous Intent discussions
Yoav Weiss
Hello blink-dev team,
For now, we are looking to prototype (and later launch) the new web API (FileSystemHandle.getCloudIdentifiers()) for ChromeOS only (with GoogleDrive and OneDrive as providers). Other platforms and providers will come later, but are not prioritized yet. The first CL just started the review process.
hend...@chromium.org / hend...@google.com
PTAL, thanks!
Contact emails
Mentor: asu...@chromium.orgExplainer
https://github.com/WICG/file-system-access/blob/main/proposals/CloudIdentifier.mdSpecification
None
Summary
This proposal adds a new getCloudHandles() method to FileSystemHandle, which allows retrieval of cloud handles for a file/directory. A cloud handle consists of a vendor identifier (e.g. "drive.google.com") and a file identifier. With these, the web app can talk to the cloud storage provider through its APIs directly to retrieve/modify the file. This is useful for web apps to figure out if a file is already backed by cloud storage and allows for easier transfer across machines as just the identifier instead of the entire file contents needing to be transfered.
Blink component
Blink>Storage>FileSystemMotivation
Web apps interacting with files/directories via file system access web API can benefit from additional capabilities when they know whether a file/directory is synced via cloud storage and what ID the cloud storage provider is using for it. Use cases: * Remote file handling: If the file should be transferred to another machine, instead of uploading it from the device itself and syncing it back, we can simply pass the cloud identifier for the file/directory to the remote machine, which directly pulls it from the cloud storage provider and also syncs it back. * De-duplication for online document editors: For cloud-based online document editors (Google Docs or Microsoft Office 365 web), the document needs to be in cloud storage (Google Drive or Microsoft OneDrive) before it can be edited. With this API, the web app could detect that a given file is already in cloud storage and edit it directly instead of creating a new duplicate. * Drag & drop into Mail: When sharing a large file via mail, instead of actually transferring the file with the mail as attachment, the web-based mail clients could instead detect that the file is in cloud storage, request it to be shared via link and simply include the link in the mail.
Initial public proposal
https://github.com/WICG/file-system-access/blob/main/proposals/CloudIdentifier.mdTAG review
TAG review status
PendingRisks
Interoperability and Compatibility
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
Debuggability
Is this feature fully tested by web-platform-tests?
No. Testing this feature requires a cloud storage sync client (e.g. GoogleDrive / OneDrive), which is not possible to mock for WPT tests. The only test we can produce is test that the result for a local file is an empty list.
Flag name
FileSystemAccessGetCloudIdentifiers (CL just started review)Requires code in //chrome?
TrueTracking bug
https://crbug.com/1443354Launch bug
https://launch.corp.google.com/launch/4234443/approver/14472Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5130687725699072Links to previous Intent discussions
This intent message was generated by Chrome Platform Status.Thank you,Alexander Hendrich
--
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/CALjDZRCx37hwFjsJ5z5OYz0TMr9gpD_3Tk8CasG_QbSVk2Zr0w%40mail.gmail.com.