PATCH creation and Upload-Type #99
Conversation
|
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. |
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
Could be resolved with a dictionary and redirection? |
|
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. |
| If the Request-URI does not point to an existing resource, the server MAY create | ||
| a new resource if the request fullfills the preconditions of a corresponding | ||
| `POST` request. | ||
|
|
There was a problem hiding this comment.
If precondition term is used here in the same sense as in HTTP protocol specification, a set of validators for a resource state should be specified. Otherwise the term should be expanded in more clear way.
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.
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?
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? |
#98