[ 
https://issues.apache.org/jira/browse/CB-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16107891#comment-16107891
 ] 

Filip Maj commented on CB-13044:
--------------------------------

[~cjpearson] I hear you, but I think it's also important to line Cordova back 
up to its initial goal: keeping in line with web standards and enabling a web 
development process for native platforms. I think Cordova overstepped itself 
initially and just wrote up off-the-cuff APIs to give users access to whatever 
device APIs existed. I think the File API plugin is a built upon specs that 
were in draft and relevant in 2011 - and at the time I don't think that was a 
mistake (elaborated more eloquently by [~macdonst] in [a recent blog post on 
PhoneGap.com|https://blog.phonegap.com/moving-forward-6b583dcd007]). A lot of 
time has passed since then and two of those APIs are now dead. I know there's a 
feeling of nervousness around this, but Cordova is going to be around for a 
long time still, and it will always provide an API to bridge into native. There 
is a template implementation already available in the existing File API plugin 
for how to provide full access to device file systems. What's changing here is 
shrinking the boundaries of the File Plugin's APIs, and shifting the 
responsibility for no-longer-relevant parts of this API from a beleaguered and 
overburdened Cordova Project Management Committee to, hopefully, a community 
that has all the tools it needs to maintain that if they so wish.

The clear and achievable goal for Cordova to reduce its API surface and align 
itself closer to web standards that are here to stay is with the movement 
towards PWAs. They are the stepping stone that Cordova can use to reduce its 
size while still enabling web developers to bring their web applications to 
native.

On a different topic, more relevant to future direction for this plugin, TODOs 
left here:
- finish testing on android
- looks like ios 10+ and android 4.4+ will be minimum versions moving forward, 
but post full test details here once complete.
- need to take a look at how to eliminate cdvfile:/// and consolidate on 
bloburls which is the way forward w/ W3C.

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

Reply via email to