[
https://issues.apache.org/jira/browse/CB-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj updated CB-13044:
---------------------------
Description:
Part of the roadmap for the core plugins is to update them to make them
spec-relevant once more. See CB-12715.
After taking a look at the current version of [W3C File
API|https://w3c.github.io/FileAPI/], here is one take on what specific API
changes are needed to update the API to the current version:
- *remove* a bunch of APIs, specifically:
-- everything to do with the [old (now discontinued) File System
API|https://www.w3.org/TR/file-system-api/]:
--- {{window.requestFileSystem}} method
--- {{LocalFileSystem}} object
--- {{FileSystem}} object
--- {{Flags}} object
--- {{Metadata}} object
--- {{Entry}}, {{DirectoryEntry}} and {{FileEntry}} objects
--- {{DirectoryReader}} object
-- everything to do with the [old, discontinued File Writer
API|https://www.w3.org/TR/file-writer-api/]: {{FileWriter}} object
-- {{FileUploadOptions}}, {{FileUploadResult}} objects (wtf are these? I think
they are for supporting file transfer? why are they in plugin-file? lol?)
-- the {{FileError}} object, as the [latest spec says to return
{{DOMException}}|https://w3c.github.io/FileAPI/#failureReason]
- update a bunch of APIs, specifically:
-- update {{FileReader}} interface's {{readAs*}} methods so that they take a
{{Blob}} object instead of a {{File}} object as parameter
-- if the polyfill is still needed, might need to update the {{File}} object
and remove a bunch of extra native-y cruft like "type" and stuff that was used
when leveraging the bridge
-- update any error handling to return {{DOMException}} instances instead of
the now-removed {{FileError}}
- possibly write up a polyfill for {{Blob}} ? Looks like it will be needed in
Android 4.4 or lower.
- possibly write up a polyfill for {{FileList}} (as per
[spec|https://w3c.github.io/FileAPI/#dfn-filelist]) - might be needed on iOS
9.3 / Android 4.4. Worth noting that the first descriptive text in the spec
mentions this interface being "at risk" as it's basically a glorified array.
- review docs:
-- are referencing local file system paths like {{<img
src="cdvfile://filesystem/path">}} still relevant (related to open question #2
below)?
-- review and update
https://cordova.apache.org/docs/en/latest/cordova/storage/storage.html#indexeddb
- it mentions some things like indexeddb has a 5MB storage, we should probably
update it to mention it is supported in ios, and do some quick checking on max
storage size.
-- remove
https://cordova.apache.org/docs/en/latest/cordova/storage/storage.html#filesystem-api
-- how much of this documentation should reside in the File plugin docs vs. in
the general "Storage" cordova docs, or perhaps even the platform docs? over
half of the File plugin docs talk about filesystem formats and platform quirks
therein.
A few open questions:
1. One thing worth noting is that platform implementations for a lot of the
above may not be needed on iOS 10+ and Android 5.0+. Would need to check
windows / edge support. If support is splotchy, we need to keep in mind to
write the plugin in such a way that we don't clobber over
potentially-pre-existing spec-adhering objects of the File API.
2. Worth calling out that the [File API defines its own URL scheme to
use|https://w3c.github.io/FileAPI/#url]. Does this then supercede the cordova
custom ones like cdvfile:// and other protocols?
was:
Part of the roadmap for the core plugins is to update them to make them
spec-relevant once more. See CB-12715.
TODO:
- Determine what needs to be updated. Check out http://w3c.github.io/FileAPI
- How can we write the plugin i such a way that we don't clobber over
potentially-pre-existing spec-adhering objects of the File API?
> Update cordova-plugin-file to latest version of File API
> --------------------------------------------------------
>
> Key: CB-13044
> URL: https://issues.apache.org/jira/browse/CB-13044
> Project: Apache Cordova
> Issue Type: Task
> Components: cordova-plugin-file
> Reporter: Filip Maj
> Labels: plugins-next
>
> Part of the roadmap for the core plugins is to update them to make them
> spec-relevant once more. See CB-12715.
> After taking a look at the current version of [W3C File
> API|https://w3c.github.io/FileAPI/], here is one take on what specific API
> changes are needed to update the API to the current version:
> - *remove* a bunch of APIs, specifically:
> -- everything to do with the [old (now discontinued) File System
> API|https://www.w3.org/TR/file-system-api/]:
> --- {{window.requestFileSystem}} method
> --- {{LocalFileSystem}} object
> --- {{FileSystem}} object
> --- {{Flags}} object
> --- {{Metadata}} object
> --- {{Entry}}, {{DirectoryEntry}} and {{FileEntry}} objects
> --- {{DirectoryReader}} object
> -- everything to do with the [old, discontinued File Writer
> API|https://www.w3.org/TR/file-writer-api/]: {{FileWriter}} object
> -- {{FileUploadOptions}}, {{FileUploadResult}} objects (wtf are these? I
> think they are for supporting file transfer? why are they in plugin-file?
> lol?)
> -- the {{FileError}} object, as the [latest spec says to return
> {{DOMException}}|https://w3c.github.io/FileAPI/#failureReason]
> - update a bunch of APIs, specifically:
> -- update {{FileReader}} interface's {{readAs*}} methods so that they take a
> {{Blob}} object instead of a {{File}} object as parameter
> -- if the polyfill is still needed, might need to update the {{File}} object
> and remove a bunch of extra native-y cruft like "type" and stuff that was
> used when leveraging the bridge
> -- update any error handling to return {{DOMException}} instances instead of
> the now-removed {{FileError}}
> - possibly write up a polyfill for {{Blob}} ? Looks like it will be needed in
> Android 4.4 or lower.
> - possibly write up a polyfill for {{FileList}} (as per
> [spec|https://w3c.github.io/FileAPI/#dfn-filelist]) - might be needed on iOS
> 9.3 / Android 4.4. Worth noting that the first descriptive text in the spec
> mentions this interface being "at risk" as it's basically a glorified array.
> - review docs:
> -- are referencing local file system paths like {{<img
> src="cdvfile://filesystem/path">}} still relevant (related to open question
> #2 below)?
> -- review and update
> https://cordova.apache.org/docs/en/latest/cordova/storage/storage.html#indexeddb
> - it mentions some things like indexeddb has a 5MB storage, we should
> probably update it to mention it is supported in ios, and do some quick
> checking on max storage size.
> -- remove
> https://cordova.apache.org/docs/en/latest/cordova/storage/storage.html#filesystem-api
> -- how much of this documentation should reside in the File plugin docs vs.
> in the general "Storage" cordova docs, or perhaps even the platform docs?
> over half of the File plugin docs talk about filesystem formats and platform
> quirks therein.
> A few open questions:
> 1. One thing worth noting is that platform implementations for a lot of the
> above may not be needed on iOS 10+ and Android 5.0+. Would need to check
> windows / edge support. If support is splotchy, we need to keep in mind to
> write the plugin in such a way that we don't clobber over
> potentially-pre-existing spec-adhering objects of the File API.
> 2. Worth calling out that the [File API defines its own URL scheme to
> use|https://w3c.github.io/FileAPI/#url]. Does this then supercede the cordova
> custom ones like cdvfile:// and other protocols?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
