Export unsubscribe message to handler

[tanghaowillow]

Application should be interested in unsubscribe message as well.

[tanghaowillow]

The test is not implemented in a clean way yet. Maybe storing the messages with an array in the handler and checking the messages later would be better?

[mengelbart]

Thanks @tanghaowillow! The reason why it was not exported yet is that I was hoping to find a way to export it via the local track instead of the message handler. This could be done by returning a special error or an extra return value from writing to the local track. I think that would have the advantage that a publisher can get the signal directly from where it would probably be handled instead of having to communicate it from the message handler to the goroutine using the local track object. What do you think about this?

[tanghaowillow]

@mengelbart Thanks for the info! I see, functionally an app can still check the error to find unsubscribe happens. But from a perspective of api design, currently only a part of messages/events informs application or upper layer, what is the consideration here?

[mengelbart]

The problem with just returning an error is that it would be ok to send more data even after the write call returned an error, which is somewhat counterintuitive. So, I wonder if another return value indicating the subscriber wants to unsubscribe might be better. But that value would likely be false most of the time.

I tried to only use the Handler interface for messages that need to be handled and where there is no other signal to surface the event to the application. E.g., Subscribe and Fetch are used to create new tracks. The corresponding error messages, on the other hand, don't need to be handled because the Subscribe and Fetch API calls of the session will notify the application about the error.

[mengelbart]

@tanghaowillow let's keep this open for now. We could also merge this approach and test if it is useful for applications. If not, we can still change the API later.

@tobbee, what do you think would be most useful for your application?

[tobbee]

I'm aiming for a controlled bitrate switching, which seems to be tricky as discussed in the Switch proposal.

I'd like the application to be notified first, and let the application trigger the "localtrack.unsubcribe". It can then do some book-keeping and possibly even send of the last object in an ongoing group before closing the track (may be hard give the current moq-transport draft, though).

On the server (publisher) side, I'd also like to have visibility into the sessionID or similar, so that I can understand and do book-keeping on what track streams belong in the same session. For Switch, but also otherwise, I'd also like to see
the subcriptionID propagated together with the message.

Maybe we can extend the Publisher interface with two methods SessionID() uint64 and SubscriptionID() uint64?