-
Notifications
You must be signed in to change notification settings - Fork 16
Description
There is a lot of redundancy in headers for Braid subscriptions:
- Each update can repeat the resource's metadata, like
Content-TypeandMerge-Type - Each patch can repeat the
Patch-Type
Example:
HTTP/1.1 209 Subscription
transfer-encoding: chunked
content-type: text/plain
merge-type: sharejs-ot
current-version: "ABC"
version: "B"
patches: 1
patch-type: ot-text-unicode <-- redundant
patch-length: 7
[1,"b"]
content-type: text/plain <-- redundant
merge-type: sharejs-ot <-- redundant
patches: 1 <-- redundant
version: "C"
patch-type: ot-text-unicode <-- redundant
patch-length: 7
[2,"c"]
content-type: text/plain <-- redundant
merge-type: sharejs-ot <-- redundant
patches: 1 <-- redundant
version: "D"
patch-type: ot-text-unicode <-- redundant
patch-length: 7
[3,"d"]
This has been cropping up in other issues, notably: #106
I currently see three ways to address this.
(1.) Updates could inherit the headers from previous updates by default, and then override any that should be different.
(2.) Patches could inherit the headers from the higher-level updates. Specifically, this is the proposal in #106, which would let you specify the Patch-Type as a top-level header in a subscription, that all patches would inherit from by default.
(3.) Use HTTP/2 header compression (called HPACK) to reduce redundancy in general.
In summary, this boils down to:
- Use HPACK in HTTP/2, or:
- Define an inheritance process
- Across time, inheriting from the past
- Across hierarchy, inheriting from higher levels in the hierarchy
(Note that I'm presuming we're moving from a 3-level hierarchy to a 2-level hierarchy, as articulated here.)