Transmitter needs ability to dictate what data it wants to share

[appsdesh]

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.

There could be scenarios where transmitter is in better position to know what data the receiver should have.

The present or future, legal frameworks, might also require the transmitters to control/filter out the data flow to the receivers.

[tulshi]

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.

[appsdesh]

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 -

1. Transmitter updated stream subjects
2. Transmitter removed an event from the stream subscription

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

[appsdesh]

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

[tulshi]

@appsdesh what is the status of this issue? Do the spec changes in the run up to ID-2 fix this?