Re: Resumable Upload draft updates

Hi Micheal!

> To best-support streaming resources of unknown length, we could
articulate more into the Version-Type. For instance, we could define a
special version ID called "end" that signals the end of a bytestream.

It's interesting to see that our efforts converge to similar approach, even
if they use different terminology. But it's reassuring that this is a
sensible method for enabling resumable uploads :)



On Thu, Jul 25, 2024 at 1:15 PM Michael Toomim <toomim@gmail.com> wrote:

> Marius, these are excellent questions! I am answering them inline below:
>
> 1. What is the parent version of a resource that a client is uploading to?
> Requests have to set this header to ensure they are appending at the
> correct offset, but I am wondering what parent version would be included in
> responses to HEAD requests. The example responses in section 3.3 always use
> the 0 byte count.
>
> Ah, yes... Well, the parent header is actually redundant in that case— so
> I'm removing it from the example.
>
> There, I think this
> <https://github.com/braid-org/braid-spec/commit/9e9485cdd4d2adcb0e7898b13919b06dc12ec496>
> is clearer now. How about you?
>
> 2. Can a client upload from a streaming data source without knowing the
> entire file size upfront? Is the including of the Current-Version header
> mandatory when starting an upload?
>
> To best-support streaming resources of unknown length, we could articulate
> more into the Version-Type. For instance, we could define a special version
> ID called "end" that signals the end of a bytestream.
>
> Then the initial request might look like this:
>
> PUT /something
> Current-Version: "end"
> Version-Type: bytestream
> Content-Length: 900
>
> <binary data of length 900>
>
> Then the client could break up the file into multiple requests, e.g. by
> choosing a smaller number than 900 above, like you ask here:
>
> 4. Does the method allow the client to split an upload across multiple
> requests? In our experience, servers can have an upper limit on the size of
> a single request, which requires a client to split an upload and send
> multiple consecutive requests to transfer the entire file.
>
> Good question! I had to think on my feet to answer this one. :)
>
> Finally, as for Content-Range:
>
> 3. The example request for case B in section 3.3.2 includes the
> Content-Range header, which appears redundant. Does its value carry
> additional information that is not covered by Parents, Current-Version or
> Content-Length?
>
> You're right that this is redundant information, but it might be useful
> for a Proxy that doesn't understand the bytestream version-type. It could
> still cache this range of the file! That's one of the cool things about
> re-using other headers and concepts. :)
>
> These are such illustrative questions! It's really nice talking to other
> people who think about these things. :) Thanks for doing so!
>
> Michael
>