RE: [Exposed] attribute on our APIs

I'm not extremely familiar with how this would be specified, but here is what I think is needed:
- Define in the Media Capture and Stream specification how MediaStream and MediaStreamTrack objects should implement HTML5 structured cloning (http://www.w3.org/TR/html5/infrastructure.html#structured-clone). Since these objects already support cloning, it might simply be a matter of mentioning that a structured clone is the result of implicitly calling the .clone() method?
- Make sure that the MediaStream and MediaStreamTrack APIs are accessible from non-window contexts.
- Have the ImageCapture APIs accessible from non-window Worker contexts as well.

For the use case I mentioned previously, the work would be in both APIs.

The structured cloning change would mean that a source can be accessed through track objects in different, potentially unrelated contexts. In particular, a page could obtain access to a media source and send its stream object to an iframe running in another domain. From a user perspective, I do not think this is a concern since the user already trusted the app to basically do anything it wants with the captured source. However, I have no idea what the implications are on browser implementations.

This does however open the door to very interesting approaches, such as:
- Media source processed by background worker (my previously described use case)
- Media source acquired by installed browser app/extension then "transferred" to regular page for sharing/display. This could be an implementation path for some privileged "output" streams such as tab capture. 
- Media displayed/rendered in other windows of an app. E.g. allowing an app to pop out a video stream outside of its main UI. (Inaki's use case)

I'd be happy to help writing a specific proposal, I'm just not sure how to do it right.

Mathieu
________________________________________
From: Harald Alvestrand [harald@alvestrand.no]
Sent: Saturday, May 16, 2015 1:16 AM
To: Mathieu Hofman; public-media-capture@w3.org
Subject: Re: [Exposed] attribute on our APIs

Den 15. mai 2015 22:50, skrev Mathieu Hofman:
> Answering to myself here, I completely forgot about the ImageCapture API.
> I think it would be useful for this API to be available in a worker and be able to transfer a MediaStream(Track) object to a worker through postMessage.
>

Thanks for the input!

Would you be willing and able to provide a proposal for exactly what we
need to change in the spec in order for this to be possible?

And - should this be done as part of the ImageCapture API work, or as
part of the Media Capture and Streams specification?

> Mathieu
> ________________________________________
> From: Mathieu Hofman
> Sent: Friday, May 15, 2015 1:41 PM
> To: Harald Alvestrand; public-media-capture@w3.org
> Subject: RE: [Exposed] attribute on our APIs
>
> Sorry for missing this earlier.
>
> One use case I could see is processing of the media video track in a worker through a canvas element. Canvas can be manipulated in a worker through the CanvasProxy object. However there is no way to get the video content into the canvas from the worker, since the only path right now is through attaching the media stream to a video element and a canvas drawImage operation with the video element as source.
> Because of this limitation it's probably fine to mark the API as exposed on Window only, but I'd like us to explore this use case and see if anything can be done to support it.
>
> Mathieu
> ________________________________________
> From: Harald Alvestrand [harald@alvestrand.no]
> Sent: Tuesday, May 12, 2015 1:23 PM
> To: public-media-capture@w3.org
> Subject: Re: [Exposed] attribute on our APIs
>
> Den 04. mai 2015 19:20, skrev Harald Alvestrand:
>> On 04/29/2015 05:17 PM, Harald Alvestrand wrote:
>>> Den 22. april 2015 19:18, skrev Martin Thomson:
>>>> On 22 April 2015 at 05:16, Harald Alvestrand <harald@alvestrand.no>
>>>> wrote:
>>>>> What considerations do people know of that dictate whether or not we
>>>>> should expose APIs to workers or not?
>>>> The primary consideration is whether we want to expose them to workers.
>>>>
>>>> Maybe you should ask if anyone plans to implement X in workers.
>>>>
>>> As amended by Martin:
>>>
>>> Does anyone plan to implement any part of the Media Capture and Streams
>>> API in workers?
>>>
>>>
>>
>> With all the responses I have seen so far:
>>
>> The conclusion is that nobody plans to implement any part of the Media
>> Capture and Streams API in workers, and we'll mark all our APIs (where
>> appropriate) with [Exposed=Window].
>>
>> I'll leave this open until Wednesday afternoon, and if the conclusion
>> still stands, will take that as a consensus position and relay it to the
>> editors for implementation.
>>
>>        Harald
>>
>>
>
> The conclusion has remained standing.
>
>

Received on Monday, 18 May 2015 22:37:15 UTC