Re: [mediacapture-image] Use partial MediaStreamTrack instead of separate ImageCapture interface

I would argue against seeing `Image Capture` as a `MediaStreamTrack` partial interface on a number of grounds:
- Conceptually speaking, a sink is _not_ a capacity of the transport track, the same as a water tap is not a property of a water pipe, but an addendum to it.  Said otherwise: we have a `PeerConnection` object instead of having a `MediaStreamTrack.sendTo(...`_remote peer_`...)`; we have a `MediaRecorder` instead of having a `MediaStream(Track).record()`, etc. 
- Not all `MediaStreamTrack` types allow for valid `ImageCapture` capabilities, for example audio tracks, remote tracks or tracks coming from a `<canvas>`.   How would the API communicate to the user that she's doing something unintended? (Answer: by rejecting the Promises returned by the methods, but that would force the user to _inspect_ those rejections and intelligently parse the results, which is cumbersome). In the current API, creation of `ImageCapture` would fail if the source `MediaStreamTrack` is of the wrong type (and this is similar, e.g. to [`WebAudio.createMediaStreamSource()`](https://webaudio.github.io/web-audio-api/#widl-AudioContext-createMediaStreamSource-MediaStreamAudioSourceNode-MediaStream-mediaStream) that would fail if the wrong Track is passed).

-- 
GitHub Notification of comment by miguelao
Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/142#issuecomment-290493044 using your GitHub account

Received on Thursday, 30 March 2017 18:01:46 UTC