You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @subins2000, it seems to be thought through solution, thanks for open sourcing ;-)
Please implement direct file write with window.requestFileSystem an the possibility to continue partially downloaded file.
Let's say, peer1 send a file to peer2 and the connection is broken.
After some time, the peer1 is sending the same file to peer2. The peer2 is pointing to the partially downloaded file and the download continues where is broke.
The text was updated successfully, but these errors were encountered:
I see that winfow.requestFileSystem is a Chromium thingy. Implementing that is not a priority since the main intention of this library is cross-platform/browser file share.
As for file resuming, if the connection close in between and sender uploads the file again with the same file ID, then the transfer will be continued on the receiver side.
Hi, thanks for the answer.
I just tried with the webdrop and indeed the file transfer is resumed. However, at least in Chromium, it gets somewhat messy with the parts of the files, that need to be combined.
Hi @subins2000, it seems to be thought through solution, thanks for open sourcing ;-)
Please implement direct file write with window.requestFileSystem an the possibility to continue partially downloaded file.
Let's say, peer1 send a file to peer2 and the connection is broken.
After some time, the peer1 is sending the same file to peer2. The peer2 is pointing to the partially downloaded file and the download continues where is broke.
The text was updated successfully, but these errors were encountered: