RFC: Robust Upload System #22
Conversation
There was a problem hiding this comment.
Here are some preliminary thoughts.
I think that your second idea of tracking parts instead of the whole file as one is much more robust and gives us the features that we'd like (resuming, progress tracking, etc.). If we're all in agreement, it'd be great to see a second draft with that idea in more detail.
There was a problem hiding this comment.
Some minor requests to complete the RFC metadata, and some questions/opinions.
This actually looks about ready to go to me, once the open threads are resolved to everyone's satisfaction.
There is a lot to do for this feature, so after this is finalized, let's create an action plan and figure out how to divide up the work. Thanks @AlmightyYakob!
Co-authored-by: Roni Choudhury <[email protected]>
There was a problem hiding this comment.
I'm 99% okay with this RFC. We should clean up the section regarding whether to store the ETags on the client or the server. I believe server was the preferred choice -- to allow resuming uploads -- but correct me if I'm wrong. If so, that'd mean removing the references to the client having to send all the ETags on finalize, too.
This is the long await "S3 API RFC". Sorry for the delay, but I believe this is in a good spot now.
Fixes #20