-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Announce #643
base: main
Are you sure you want to change the base?
Announce #643
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still find some of the ANNOUNCE flow overly complex, but this does a good job of describing how you might use the defined messages.
|
||
If the subscriber is aware of a namespace of interest, it can send | ||
SUBSCRIBE_ANNOUNCES to publishers/relays it has discovered. This message | ||
increases the likelihood that publishers will send relevant ANNOUNCE messages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it required to send ANNOUNCES that match the prefix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The normative words are in the ANNOUNCE section. I had SHOULD under the general theory of "server's gonna do..." but I'll change it to MUST because I don't think it matters that much. The question is "MUST if what?" and my next edit will attempt to answer that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Individual Review:
Thanks for tackling this. There's a lot going on here.
Moving the error codes is helpful but seems like a great candidate for a standalone editorial PR.
There are some normative changes to relay handling not related to ANNOUNCE which should also be in a separate PR.
There's a subtle deletion of the "exact" namespace matching behavior. This is less problematic in the face of structured namespaces, but I forget if that was something we discussed and had consensus on?
increases the likelihood that publishers will send relevant ANNOUNCE messages | ||
for that namespace. | ||
|
||
An UNSUBSCRIBE_NAMESPACES negates the effect of a SUBSCRIBE_NAMESPACES. It does |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"negates the effect" has me reaching for a D20
@@ -855,18 +888,15 @@ namespace it previously responded ANNOUNCE_OK to by sending an | |||
ANNOUNCE_CANCEL. | |||
|
|||
A relay manages sessions from multiple publishers and subscribers, | |||
connecting them based on the track namespace. This MUST use an exact |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You removed the normative exact match
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multi-tiered namespaces don't work if we don't update this.
This PR is already heavily editing the relay section for redundant and poorly located text. This falls into that theme; it is not specific to relays.
Again, a huge rewrite of the Relay section is in scope for this.
I don't see how structured namespaces can work with exact matching. |
Fixes #556
Fixes #557
Fixes #577
Fixes #583
Fixes #584
Also eliminates text from the relay section that is redundant, because it applies to endpoints whether or not they are relays.