Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

Thanks for the info on the MediaSession spec (a spec for connecting 
function keys and UA control elements to media element states). I did 
not know about that.

That spec will have to live or die on its own.


On 6/15/21 8:41 AM, Youenn Fablet wrote:
>
>
>> On 15 Jun 2021, at 08:07, Harald Alvestrand <harald@alvestrand.no 
>> <mailto:harald@alvestrand.no>> wrote:
>>
>> Embedding the specific UA controls in the browser (proposal A and B) 
>> is a layering violation.
>>
> I am not sure to understand what you mean by layering violation, can 
> you clarify?
> Media Session spec already exposes 
> togglecamera/togglemicrophone/hangup as a way to implement video 
> conferencing specific UA controls in the browser, 
> https://github.com/w3c/mediasession/issues/264 
> <https://github.com/w3c/mediasession/issues/264>.
>>
>> The WebRTC API and the platform does not offer a presentation 
>> feature; it offers a platform on which applications can be built, 
>> some of which embed the concept of "forward slide" and "back slide".
>>
> MediaSession spec defines previoustrack/nexttrack, which do not have a 
> default handler, it is up to the web application to implement them.



> The web platform does not implement these natively but applications do 
> and the web platform acknowledges that.
> This seems similar to “forward slide” and “back slide”.


But the MediaSession spec assumes that there are UA elements that exist 
beyond the page's control (such as physical buttons or lock-screen 
controls) that map to these functions (if they exist).

In our (example) case, we're dealing with functions that have no 
corresponding UA elements - the controls are defined by one page, and 
the actions are carried out by another page. There's no need to define 
them in an UA spec, and I believe it's actively harmful to do so.