(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 https://github.com/braid-org/braid-spec/issues/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.)
There is a lot of redundancy in headers for Braid subscriptions:
Content-Type
andMerge-Type
Patch-Type
Example:
This has been cropping up in other issues, notably: https://github.com/braid-org/braid-spec/issues/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 https://github.com/braid-org/braid-spec/issues/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:
(Note that I'm presuming we're moving from a 3-level hierarchy to a 2-level hierarchy, as articulated here.)