Allow multiple patches per version about braid-spec

[mitar]

This is now possible for range patch. If braid starts using range patches now, then you get this for free.

[toomim]

I think this is possible when a client sends a patch, but not when it receives a patch. So I think this is still an issue.

This is also an issue with the patch format: 606f2f1#r35759176

Maybe we can solve these two problems with the same mindset.

[mitar]

I think this is possible when a client sends a patch, but not when it receives a patch

Receiving a multipart patch is already defined in the original Range specification. That is the main use case there.

This is solved already. Not sure what is unclear here. I should just clarify it in the spec. Please open an issue for that.

(This issue is for updating the language in braid HTTP spec.)

[toomim]

The issue is that the subscriptions part of a GET request already has a form like a multipart-body. So what we're talking about here is to put a multipart/bytes body within a multipart subscription body.

Maybe that's ok. Maybe that works. But I think we might need to at least give an example of it, because it's kinda weird.

[mitar]

It is multipart/byteranges inside the whatever subscriptions does. It works because it will use different delimiters.

[toomim]

Notably, the current spec for multipart GET subscriptions uses a Content-Length delimiter to decide how long each part will be, rather than the unique string.

In some sense, it's nice to use a different syntax for separating the outermost multipartness from the inner multipartness.

In another sense, it's ugly to have two different ways of doing the same thing.

[toomim]

Here's how the outer one works:

2.2.  Sending multiple updates per GET

  To send multiple updates, a server concatenates multiple sub-responses
  into a single response body.  Each sub-response MUST contain its own
  headers and body.  Each sub-response's headers MUST contain a

          Content-Length: N

  header, where N is specified in bytes.  The sub-response body MUST be
  exactly N bytes, and be followed with a single newline.  Any data
  after this newline begins the next sub-response's header.

  Each response MUST have both headers and a body.  The body MAY be
  zero-length.

[mitar]

I think both of those combinations would work together. I slightly prefer mutlipart with unique strings because it looks that this is more used in HTTP, but I do not know really. Have you taken this approach of content-length use from somewhere else? I think that probably the content-length approach is a problem because you cannot stream the thing. With delimiter you can pick a delimiter, start streaming the stuff, and then finish with the delimiter. With content-length you have to know the size of the thing in advance. But that is maybe always possible?

[toomim]

You can't stream with a string delimiter either, because that delimiter might appear in the content. So you have to read it all first, to make sure that your string doesn't appear in there.

In any case, we can handle streaming case by breaking up a single patch into multiple patches.

[mitar]

You can't stream with a string delimiter either, because that delimiter might appear in the content.

I think with enough long delimiter this is so low probability that it cannot really happen.