W3C home > Mailing lists > Public > public-webscreens@w3.org > September 2019

Re: [openscreenprotocol] Multiple controllers of remote playback (#149)

From: Peter Thatcher via GitHub <sysbot+gh@w3.org>
Date: Sun, 15 Sep 2019 22:09:01 +0000
To: public-webscreens@w3.org
Message-ID: <issue_comment.created-531603599-1568585340-sysbot+gh@w3.org>
> > On a blank/empty HtmlMediaElement? What if it's not empty? Does it change the source of the remote element?
> 
> Maybe there can be two methods: one that always uses the controller's source, and another method that overwrites the local element with the receiver's media, if there already exists a session. This would let the site choose the behavior.

That's an option.  Another is one method with a good default (like pull is default and push is an opt-in override parameter).

The more I think about it, the more I think push is a better default and if you want pull, just clear your own source before you remote, or make a blank one.  So I think I like "one method with push".

> 
> Alternatively, prompt() can handle all the cases, and the user can choose in the UA's UI which source to use. Then the controller page would know which by looking at the currentSrc (or src?) This would let the user choose the behavior.

That sounds too complex from a UX perspective.  

> 
> We need to handle cases where we're using the receiver's source and the media types are different (<audio> vs <video>) between the controller and receiver elements. We can require the controller UA to prevent such reconnects, or throw an error. I think the former is a better UX.
> 

I think preventing reconnects make sense.

> > What can Presentations do right now?
> 
> It requires that the reconnecting PresentationRequest already knows the receiver's URL: ["Its presentation URL is equal to one of the presentation request URLs of presentationRequest"](https://w3c.github.io/presentation-api/#reconnecting-to-a-presentation). Its Remote Playback equivalent would be for the HTMLMediaElement to already have the media URL (or just the origin?) as a source, which I don't think is practical.

Oh, that's interesting.  In that case, we wouldn't have to deal with push vs. pull. 

But why would this be impractical for remote playback but not for Presentation API?



-- 
GitHub Notification of comment by pthatcherg
Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/149#issuecomment-531603599 using your GitHub account
Received on Sunday, 15 September 2019 22:09:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:23:19 UTC