Comments (10)
This is now possible for range patch. If braid starts using range patches now, then you get this for free.
from braid-spec.
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.
from braid-spec.
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.)
from braid-spec.
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.
from braid-spec.
It is multipart/byteranges
inside the whatever subscriptions does. It works because it will use different delimiters.
from braid-spec.
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.
from braid-spec.
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.
from braid-spec.
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?
from braid-spec.
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.
from braid-spec.
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.
from braid-spec.
Related Issues (20)
- Heartbeat messages to prevent timeouts HOT 8
- Subscriptions with no immediate response HOT 2
- Add top level Patch-Type to subscriptions HOT 3
- What error code should we use when historical versions are missing? HOT 1
- Get requests with 'version' header should all appear in same section. HOT 3
- Allow 404s within a Subscription HOT 7
- Cache-Control is missing from the spec HOT 1
- Typo on braid.org HOT 1
- Subscription without payload HOT 6
- Compression or inheritence for headers
- Guidance for PUTs to legacy servers HOT 9
- Articulate the general form of Updates HOT 1
- Subscription parameters HOT 2
- Write Abstract Protocol HOT 3
- Place fields in correct IANA Registry
- Multi-ID versions used in text before they are explained HOT 2
- Difference between ignoring and rejecting an update HOT 3
- Reporting versioning-related errors
- Memento protocol HOT 3
- First-Readthrough Nitpicks HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from braid-spec.