Add event_types_supported to the SSF transmitter metadata

[vivshankar]

Proposal

1. Add event_types_supported to the SSF transmitter metadata to indicate the available event types for receivers to request. This potentially allows the receiver to not need to perform additional actions on its end based on the stream config response. This is proposed as an optional property for backward compatibility.
2. Allow event types other than those listed in the event_types_supported to continue to be requested and used. This would cover event types that transmitters make available to specific receivers or for "beta" purposes.

[vivshankar]

Folks, were there any thoughts given to this proposal?

[appsdesh]

This was already discussed #45

[vivshankar]

@appsdesh Thanks for tagging that issue, but it isn't clear why that would relate to what I am proposing here. The problem we are grappling as an implementer is how a receiver determines the available events that a transmitter is able to transmit. While this could be outside of the spec, I see no advantage there given the transmitter has a metadata endpoint available and can share this information directly.

I don't see anything in the other issue that indicates why this wouldn't be done.

[FragLegs]

The point raised in the issue that @appsdesh referenced is that events_supported is a function of the stream, not a function of the Transmitter. For instance, imagine there are two users: tenant 1, who is only paying for the Transmitter's basic plan, and tenant 2, who is on the deluxe plan. When tenant 1 sets up a stream, the only events supported by that stream are A, B, and C because they're on the basic plan. When tenant 2 sets up a stream, it supports events A, B, C, D, and E because they are on the deluxe plan. There is no way to express that dynamic nature in the public well known endpoint.

Can you describe in more detail the problem you are running into? Maybe we can help brainstorm a way around it.

[vivshankar]

@FragLegs I see what you mean. The main issue is there is no prescribed mechanism available to discover the event types supported by a transmitter. So the only mechanism that appears to exist for a receiver is to -

1. Find product documentation that indicates the list of event types (or speak to someone in the product support/dev team)
2. Supply the desired list in events_requested.

The transmitter can and would respond with events_delivered that indicates exactly those events that will be delivered to this stream. This could be based on the subscription plan etc.

So with my proposal, this is what the receiver would do -

1. Look up ssf-configuration for events_supported
2. Include events of interest in events_requested
3. Transmitter responds with the ones that will be delivered

It eliminates a non-prescriptive mechanism of discovering events that are supported by the transmitter, while retaining the ability to filter by subscrption plan etc.

Also, in the event that the receiver doesn't provide events_requested, the transmitter makes the appropriate decision on which events would be delivered, which may be all that are allowed based on the subscription plan entitlement etc.