-
Notifications
You must be signed in to change notification settings - Fork 10
.sendCaptureAction() seems misplaced on the track #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It does not affect all clones, or any of the clones. The tracks themselves are not affected by sendCaptureAction. The tracks are merely conduits. All roads lead to Rome - the single captured tab, and its single registered event handler.
The same reasoning (all roads lead to Rome) convinces me that it would be fine to expose on both audio and video. |
My general mental model is that a method that only impacts the track should go to the track. Having a single place for actions is a good simplification and will make things simpler. It also seems like it will be a simpler and less error prone programmatic model for web developers. Overall adding this separate container looks like a nice addition, so it seems good to have a try. |
If we want to think about exposing the source as an object, we'd better think about exposing the source as an object. Some sources (VTG, capture-from-element) are objects already, but there's no generic source object. |
track.sendCaptureAction, the API to send supported actions to the captured page seems misplaced on the MediaStreamTrack. The reasons are:
We’ve stepped out of media consumption to remote control.
A higher level object seems needed, one that isn't clonable or necessarily shared with every media consumer. Likewise, w3c/mediacapture-screen-share#190 seems to similarly need this higher level object.
See #12 (comment) for ideas on such a higher level object, which I'm scheduled to present tomorrow.
The text was updated successfully, but these errors were encountered: