Re: [DISCUSS] Revive/Undeprecate cordova-plugin-file-transfer

[Mark de Groot <ma...@markdegroot.nl>]

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 <ti...@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.brust@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
>