search

tus / tus-resumable-upload-protocol

Open Protocol for Resumable File Uploads
https://tus.io
MIT License
1.48k stars 103 forks source link

PATCH creation and Upload-Type #99

Closed ronag closed 7 years ago

ronag commented 7 years ago

98

ronag commented 7 years ago

I think this simplifies and supersedes #88

Acconut commented 7 years ago

I think this simplifies and supersedes #88

I disagree as I believe the server should be in charge of creating the upload URL and not the client. This is not only required to avoid collisions but the upload URL is sometimes used to store information about where the upload is located. For example, the AWS S3 backend for the tusd server encodes the files location inside the upload URL. In this case it would not be possible to let the client decide on the upload URL.

ronag commented 7 years ago

I disagree as I believe the server should be in charge of creating the upload URL and not the client.

While that is the best case I don't think it's always the appropriate case. In our case for example, if two clients want to upload the same file, we wan't them to share the upload resource, so we specify how the clients create the resource id (hash of file size, modified and name) and they both send PATCH and the server lets them share the upload resource.

For example, the AWS S3 backend for the tusd server encodes the files location inside the upload URL.

Could be resolved with a dictionary and redirection?

cjhenck commented 7 years ago

I'm not entirely sure why you would want multiple clients to update to the same ID as you describe in #98.

The best guess I have is that you're trying to have user-scoped IDs, so they should not conflict? If that is the case, perhaps you can just use custom metadata to append the IDs and then deal with them in your internal implementation? That is what we do in our use case: we have unique user IDs in metadata that we use to update our DB with the final upload location.

Acconut commented 7 years ago

clients create the resource id (hash of file size, modified and name)

This is not a very good approach. Trying to identify a file just by it's name, size and modification date is not enough in opinion and may eventually lead to conflicts or even corruption as clients may upload different files to the same URL.

two clients want to upload the same file, we wan't them to share the upload resource

How do you want to share an upload between two clients? Only one client may upload to the resource in order to prevent conflicts and corruption?

they both send PATCH and the server lets them share the upload resource.

If you are looking for achieving parallel uploads for greater efficiency, did you check out the Concatentation extension? It allows client to uploads parts of a file on there own and later combine them into the original file without the possibility of conflicts.

I am sorry, but I still do not exactly understand your use cases. Would you mind explaining using using a more detailed example?