Re: Resumable Upload draft updates

[Michael Toomim <[e-mail]>]

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