webdav doesn't support upload progress since v5

[Antreesy]

Reference: https://github.com/perry-mitchell/webdav-client/blob/master/CHANGELOG.md#v500

[Antreesy]

cc @marcoambrosini @szaimen since we can't get the data to fill a progress bar, maybe replace it with a spinner on top of file preview?

[nickvergessen]

Or keep it with a wrong state until the lib fixed it. It's planned to fix it, right?

[Antreesy]

It's planned to fix it, right?

We can fake a progress bar filling up, until library will be ready for it, though

[nickvergessen]

We can fake a progress bar filling up, until library will be ready for it, though

Okay, reading the linked tickets it seems it's not planned to fix this ever.
Then I guess a loading spinner or something else might be better

[marcoambrosini]

I think that this is a very essential feature, both in Talk and in Files. We should give it priority.

It looks like it is possible to measure this, can you have a stab at that? perry-mitchell/webdav-client#319 (comment)

[Antreesy]

It looks like it is possible to measure this

Library accepts and returns Stream.Readable / Stream.Writable, which are part of Node.js API, there is nothing we can use in browser. A note from Readme:

NB: Streams are not available within the browser, so createReadStream and createWriteStream are just stubbed. Calling them will throw an exception.

[Antreesy]

Differences coming with a new lib @nextcloud/upload (https://github.com/nextcloud-libraries/nextcloud-upload):

Tool	3RD webdav	NC upload
Requests	Fetch	Axios / XHR
Concurrent upload	Yes	Yes
Parallel upload	Yes (amount depends on fetch)	No (Yes, but max 3 small files without chunk)
Total upload time	Faster	Slower
Chunk upload	No	Yes (max 3 (5-10 Mb) by default atm)
Effect	File should be bufferized - high impact on browser for big files	File is read chunk by chunk
Upload progress	No	Yes (Only if loaded by chunks, shows total for queue)
Test (1 file 400Mb)	total: 24.725 s	total: 27.065 s
Test (6 files 40Mb each)	total: 12.274 s	total: 20.820 s
Test (15 files 6.2Mb in total)	total: 5.691 s	7.161 s

Tests don't consider remote requests to server (time to send/receive), so results could differ drastically in production

So, it works fine in general, but:

• we have to sacrifice upload speed from parallel upload for small files
• we can't track upload progress for a single file, when loading several at once
• we may benefit in big files upload (RAM usage)
• we need a way to track each file progress personally