Open appsdesh opened 10 months ago
This was intended to be done using the "stream updated" event. But now I see that the Stream Updated event specifies that the subject should always be the Stream ID. Should we update the description of the Stream Updated event to have additional statuses "subject added" and "subject removed"? Those events can have these details then.
Looking at the current description the stream updated event is purely used for communicating functional/operational status of the stream ie. disabled
, enabled
, paused
etc.
It does not deal with stream related metadata modification by the transmitter such as -
Maybe it's worth clarifying that the Transmitter could update the stream Metadata (not just operational status). Add reflect the reason
in the updated event. status
could still be enabled
The Event Transmitter MAY choose to silently ignore the request, for example if the subject has previously indicated to the Transmitter that they do not want events to be transmitted to the Event Receiver
I see this sentence in the add subject case.
Similarly, we can take an approach that "a transmitter silently decides which subjects it wants to transmit to the receiver". It does not need to indicate subscribed subjects to the receiver.
Since add/remove subject API response may not always indicate true state of the subscribed subjects
@appsdesh what is the status of this issue? Do the spec changes in the run up to ID-2 fix this?
Currently the spec has "add_subject", "remove_subject" as optional operations that are driven by the receiver. With these operations the receiver decides which subjects should be (or shouldn't be) part of the stream.
This overlooks the need from the transmitter's perspective it's willingness to share data regarding subjects.
The present or future, legal frameworks, might also require the transmitters to control/filter out the data flow to the receivers.