Hi Community, I want to bring some attention to https://github.com/apache/cordova-plugin-file-transfer/pull/381#issuecomment-2681913928
It appears that historically and is currently documented to use file entry `.toURL()` with File Transfer APIs. From what I've gathered, it was because `.toURL()` used to return `cdvfile:` paths, but it has gone through several evolutions since then. Including being converted to it returning `file:` paths due to cross-origin restrictions on modern webviews, to modern day (since file plugin v7 / v8) returning `file:` if app is hosted on file protocol, or using the scheme (e.g. `app:` on iOS, and `https:` on android) if using schemes. The file plugin documents using `.toURL()` to produce a DOM-usable URL, a URL that can be used in DOM elements such as `img` or `video` tags, etc, and the URL can be intercepted and parsed by our webview client to provide the relevant resource. It's intended use seems to have shifted over the years. Therefore, I want to try to come to a consensus which will probably dictate how to resolve the file transfer plugin issue linked above. I see two potential paths: 1) We treat `.toURL()` return as single purpose, an URL usable in the DOM. File entries should provide a means to get the underlying URL resource (which I believe is accessible via `Entry.nativeURL`) should an API require the native path to the resource. File Transfer plugin docs should be updated accordingly. 2) We update File Transfer to understand the DOM-usable URLs so that it can parse and extract the underlying native path, similar to how the webview would intercept the URL. This will maintain existing and documented behaviour, at the consequence of breaking the Single Responsibility Principle (https://en.wikipedia.org/wiki/Single-responsibility_principle) Looking forward for more input, Cheers -- Norman Breau <nor...@breautek.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
