The spec provides a lot of flexibility in how servers return subscription data:
The rate of updates
The granularity of updates
The format of updates (e.g. patch vs. snapshot; patch-type)
The versioning system (e.g. version-type) to use
Whether (and how) patches are rebased
How to behave if a disconnection happens
E.g. How long to hold history for offline clients
etc.
We would like clients to be able to specify how they'd like this data.
We have left room in the Subscribe: <parameters> header to specify these parameters. This issue is a spcae to design the parameters spec. What options should exist in there? How should they be specified?
@CxRes also points out that subscription parameters are defined via the Accept-Events: header in his PREP proposal, and we could use that for reference.
The spec provides a lot of flexibility in how servers return subscription data:
We would like clients to be able to specify how they'd like this data.
We have left room in the
Subscribe: <parameters>
header to specify these parameters. This issue is a spcae to design the parameters spec. What options should exist in there? How should they be specified?See the Structured Headers rfc8941 for reference on how to structure header values in HTTP.
This issue consolidates discussions from: https://github.com/braid-org/braid-spec/issues/80 (
keep-alive
), https://github.com/braid-org/braid-spec/issues/92 (rebase mode), https://github.com/braid-org/braid-spec/issues/101 (rebase mode), and https://github.com/braid-org/braid-spec/issues/115 (rate & format of updates), and should be consider the discussion in https://github.com/braid-org/braid-spec/issues/105.