Closed canadaduane closed 1 year ago
I see from section 3.3 that my concerns are mostly addressed:
Even if a connection closes, a subscription might still be active.
If a server's response headers for a connection contained:
Subscribe: keep-alive
or Subscribe: keep-alive=<seconds>
Then the server SHOULD keep the subscription open even after the
connection closes. This means that the server promises to keep
enough history to merge with the client when the client comes back
online.
So it sounds like the idea is that a server's "maximum memory footprint" over the set of all clients that subscribe to it is simply whatever data the server is storing for state, and related history. I.e. there is no information specific to each client. Is that right?
Thanks Duane! That text in section 3.1 looks misleading to me, and I think we should clarify it. It implies that the client controls how long the subscription will stay open—but our intent when writing this was for the server to make the final call.
As to whether the server needs to store information specific to each client — that's up to the server! The spec doesn't force servers to obey subscription requests, nor does it say how the information should be stored. I can imagine server implementations that don't keep information specific to each client, and implementations that do.
So language should be:
If a client requests "Subscribe: keep-alive", then the subscription CAN be
remembered even after the GET connection closes. A subscription CAN
be resumed by the client issuing another GET with a Subscribe header.
So see CAN there? Or we could use some other similar word.
MAY might read better
Consensus:
Subscribe: true
.In the future, it's possible that we could invent other parameters for Subscribe, such as:
Subscribe: duration=connection, update=snapshot,patch
The update=snapshot,patch
attribute is relevant to @brynbellomy's redwood protocol work as well.
We still need to write a PR to change this.
I wrote a PR for this at https://github.com/braid-org/braid-spec/pull/122.
Note that I broke from consensus in a sense by writing all the examples with blank Subscribe:
headers. The description suggests Subscribe: true
, but I fear implementors blindly requiring true
on a server without reading that true
is optional, and then the servers will break if clients start replacing true
with more nuanced parameters, instead of gracefully ignoring the parameters that they don't understand.
Closing this issue. All discussion of subscription parameters are now being consolidated to https://github.com/braid-org/braid-spec/issues/123.
In section 3.1 it says:
Two concerns: