RFC: Fetch is dead #1377
RFC: Fetch is dead #1377
Conversation
| SUBSCRIBE_OK in response to a downstream SUBSCRIBE. If a relay does not have | ||
| sufficient information to send a FETCH_OK immediately in response to a FETCH, it | ||
| MUST withhold sending FETCH_OK until it does. | ||
| sufficient information to send a SUBSCRIBE_OK, itMUST withhold sending |
There was a problem hiding this comment.
| sufficient information to send a SUBSCRIBE_OK, itMUST withhold sending | |
| sufficient information to send a SUBSCRIBE_OK, it MUST withhold sending |
|
Having "fetch" functionality within Subscribe or as a separate message has been discussed in the past. Following the slides (slides 16-17) and then the subsequent PR. I am curious whether we should reopen this discussion. Having something in the spec for 1.5 years and having people implement it, then changing it completely, I think, deserves some strong justification. Keeping Subscribe and Fetch separate, I thought, was also something those who did not want to implement Fetch wanted in the first place. |
| and previously published Objects are delivered on a single unidirectional | ||
| stream, allowing the receiver to apply flow control. | ||
|
|
||
| There are 4 types of subscriptions: |
| Code | Subscription Type | ||
| 0x0 | Only newly published Objects | ||
| 0x1 | Only previously published Objects | ||
| 0x2 | All previously and newly published Objects |
There was a problem hiding this comment.
The wording is a bit confusing. "All previously ..." may be interpreted as we need to send the whole history of the track. Maybe "Both previously and newly published objects"? Or "Some previously published objects and the newly published objects"?
| * Parameters: The parameters are defined in {{version-specific-params}}. | ||
|
|
||
|
|
||
| ## UNSUBSCRIBE {#message-unsubscribe} |
There was a problem hiding this comment.
why is UNSUBSCRIBE dead as well? Collateral victim?
There was a problem hiding this comment.
Indeed, it still shows up in one place (likely to be a leftover) but why are we removing Unsubscribe for terminating the sessions?
Removes Fetch and Joining Fetch in favor of moving to a Subscribe model that uses a single bidirectional control stream per Subscription. Does not change how Objects are sent.
Removes Request ID from SUBSCRIBE_UPDATE, but not entirely.
Adds the 'Relative Past Group (0x5)' filter type to replicate the relative joining fetch functionality.
Some open PRs need to land for this to fully come together, so this is more of a proof-of-concept.
Fixes #1343
Fixes #1313
Fixes #1168
Fixes #1039
May Fix #861