Closed dkocher closed 5 months ago
Could you elaborate a bit more on concrete use cases? In what scenarios would the client not be able to persist upload URLs but still be interested in resuming uploads?
Could you elaborate a bit more on concrete use cases? In what scenarios would the client not be able to persist upload URLs but still be interested in resuming uploads?
We are discussing an implementation in Cyberduck ^1. In this use case the user might abort an upload. The extension to discover an existing upload URLs for a filename would allow to prompt the user to resume a transfer that is initiated later with no context of the previous action.
The client application usually keeps track of which uploads it started and didn't finish. For example, tus-js-client automatically persists information about the uploads in a device-local storage. Once the application wants to resume an upload, it can query this storage for related uploads and resume accordingly. Upload resumption will usually be performed by the same device that created the upload because typically the file isn't available magically on another device. This removes the need for a server to look up which uploads are available for resumption.
Is there a specific reason why you don't want to use device-local storage?
My intention was to allow for easier client implementations without the requirement for storage. Looking at the overall picture I agree keeping the protocol lean should probably be the priority instead. The use case with different devices and/or client applications uploading the same file is probably not a common concern.
Currently client implementations must persist the Upload URL. I propose an extension that allows the discovery of existing upload URLs for unfinished uploads based on metadata. Similar to
ListMultipartUploads
^1 in S3.