search

Dash-Industry-Forum / Events

Addresses discussions around Event Processing and APIs
2 stars 6 forks source link

some comments on webidl interface #39

Closed RufaelDev closed 5 years ago

RufaelDev commented 5 years ago

some comments on WebIDL event API

  1. promise not needed/needed ? why promise on SetEvents
  2. consider geting Events from HTML media element (not source buffer, as there will be many, it will be confusing to set up all event handlers)
  3. event object, on callback the eventHandler field and desiredScheme will not be set, consider separating the eventdispatcher (with handler and desired schemes) and event object containing eventData (containing the event instance).
gmandyam commented 5 years ago
  1. promise not needed/needed ? why promise on SetEvents

It is assumed to be an asynch call. Particularly if it ends up tying in to a platform call (which is the case with e.g. ATSC TV sets), then a synchronous call will be blocking.

  1. consider geting Events from HTML media element (not source buffer, as there may be many, it will be confusing to set up all event handlers)

This would require a modification of the HTMLMediaElement. I don’t have a strong opinion against doing that, but the existing events hanging off of HTMLMediaElement don’t really have a subscription model. The app just sets up the event handlers for events it is interested in e.g. volumechange, onloadeddata, etc.

  1. event object, on callback the eventHandler field will not be set on the event instance, consider separating into eventdispatcher (with handler and function for setting schemes) and event object containing eventData (containing the event instance). This also reflects my earlier comment on state, the dispatcher (handler) will be stateless but the eventData will be refreshed on callbacks, so perhaps better to separate the two objects. If there was some reason for this design, please help us understand it,

The API is an EventTarget. There will be something returned when the associated DASH event fires (eventData), and it will be returned to an eventHandler. The implementation has to invoke the handler when an event occurs, otherwise it would not be a valid implementation. I modeled this design off of the MediaRecorder API (https://w3c.github.io/mediacapture-record/), which has been implemented in both Chrome and FF. In that case, RecordingState’s current value is consistent with the most recently fired event. I can understand a dislike of EventTargets in general (they are not really that popular among developers), but that doesn’t mean that they don’t work.