Hi all, I agree this plugin still has it's value in the cordova universe and (at times) works way better than the proposed alternative using XHR. I ran some tests downloading a 70 MB file. Using cordova-plugin-file-transfer this takes about 35 seconds. Downloading using XHR took 30 seconds as well, but now the file still has to be saved using cordova-plugin-file which took another 50 seconds resulting in a total download time of 80 seconds!
I've elaborated more on this in this github issue: https://github.com/apache/cordova-plugin-file-transfer/issues/266 Bottom line: Keep this plugin active! It looks like there are enough people willing to contribute to the code and a lot of people depending on the functionality. Kind regards, Mark On 2020/07/23 09:23:38, Tim Brust <tim.br...@sinnerschrader.com.INVALID> wrote: > Hi there, > > I'd like to discuss the revival of the cordova-plugin-file-transfer plugin. > With the decision from 2017 it was sunsetted and the XHR/fetch alternative > was proposed. [1], [2] > > However, neither the plugin was deprecated on npm nor the GitHub repository > archived. > With the release of cordova-ios@6 it is no longer usable. [3] No surprise > given the fact no work as has been done on the plugin in the recent years. > > However, it seems that > 1. A lot of people are still relying on the plugin - the count of unique > users that commented, opened a duplicate issue or reacted to comments is > (IMHO) very high compared to other issues (and I read at least 90% of our > newly opened issues). [3] > 2. There are reasons to *not *use XHR/fetch. Personally, I've experienced > out of memory issues which resulted in white screens and page reloads on > iOS with big files. If it helps, I can try to provide an example app that > showcases the issues with XHR/fetch. > > We've created a fork at work and applied a lot of the recent fixes we did > for other plugins, too, such as removing deprecated platforms, migrating to > @cordova/eslint, cleaning up the package.json files and npmignore list. > I'm happy to contribute those commits back to the original plugin, as the > work is done anyways. > > The same discussion could be applied to other plugins, too. There is a > general tracking issue: [4], take a note at especially this comment [5] > I'll link this mailing thread to the issue [4], too, and ask affected users > to give some more input why they can't migrate to XHR/fetch, too. > > Looking forward to hearing from you and your opinions. > > Best, > Tim > > Links: > [1] - > https://cordova.apache.org/blog/2017/10/18/from-filetransfer-to-xhr2.html > [2] - https://issues.apache.org/jira/browse/CB-13052 > [3] - https://github.com/apache/cordova-plugin-file-transfer/issues/258 > [4] - https://github.com/apache/cordova/issues/185 > [5] - https://github.com/apache/cordova/issues/185#issuecomment-569979586 > -- > Tim Brust, Product Engineer > > tim.br...@sinnerschrader.com > > SinnerSchrader Deutschland GmbH | SinnerSchrader Group > Völckersstraße 38, 22765 Hamburg, Germany > > Amtsgericht Hamburg HRB-Nr. 63663 > Geschäftsführer: Matthias Schrader (Sprecher), > Jürgen Alker, Dr. Axel Averdung, Holger Blank, > Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner, Peggy Hutchinson > > Büros: Berlin, Hamburg, Frankfurt a. M., München, Prag > > https://www.sinnerschrader.com | NEXT AGENCY >
