- From: Duan Yao via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Jul 2015 02:48:16 +0000
- To: public-secondscreen@w3.org
I don't think limiting remote presenting to media elements is a good
idea. E.g. what if one want to use a video player with custom UI?
This is my proposal (was posted to the mail list ["extend fullscreen
API to support second
screen"](https://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0074.html)
):
```
Local UA network
Remote UA
a Element -----------captured live video
stream-------> a HTMLVideoElement
(requestSecondScreen(), <----------input
events---------------------- (fullscreened, RDP client)
RDP server)
|
|
|
::mirror
(pseudo-element,
a local RDP client)
```
To summarize:
* Any local element can `requestSecondScreen()` (a remote version of
`requestFullscreen()`). If succeed, the element is _projected_ to the
remote UA.
* The local element projected act as a
[RDP](https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) server,
while the remote UA create a special HTMLVideoElement which acts as a
RDP client, and connects to the RDP server. (Not saying that we must
use RDP, just an example). The projected element is rendered locally,
but according to the dimension of the remote screen. Input events of
the second screen are sent back to the local UA to process.
* There is a pseudo-element `::mirror` act as a local RDP client in
place of projected element to show a scaled-down view of it.
* No cross-document messaging required, and client code just feels it
is working with a single document.
--
GitHub Notif of comment by duanyao
See
https://github.com/w3c/presentation-api/issues/13#issuecomment-125416953
Received on Tuesday, 28 July 2015 02:48:18 UTC