Re: Presentation API changes proposal

Hi Wes,

On 10 Jan 2014, at 21:00, Wesley Johnston <wjohnston@mozilla.com> wrote:

> I'm curious, what does this second UA proposal solve that isn't already covered by the Network Service Discovery API [1]?

> It looks like it would provide enough information to detect a second UA device on the network, along with the ability to communicate with the device (or you could set up a peer connection).

Yes, I agree. Network Service Discovery would indeed be a viable way to do that. However, Anton mentioned the reservations towards Network Service Discovery API. For our CG, the main focus is to allow access to secondary screens and thus close the gap to native applications. The goal is not to develop a solution for cross-UA distributed applications. 

For secondary screens there are of course several underlying connection technologies: Wired connections like HDMI or DVI, Miracast, Airplay, DLNA, ... - and Chromecast.

In most of the above cases on the implementation side we can just rely on OS abstractions that manage the screen dimensions, connection setup etc. for us. In the Chromecast case there’s more work to do on the application side, not the OS side. Or in other words, there are no OS level abstractions for using a Chromecast device as a display destination. And Chromecast is build on web technologies and is designed to have that secondary UA.

So, by relaxing the tight coupling (WindowProxy) to a MessagePort, there is more flexibility on the implementation side, and Chromecast can be covered more easily as one of those connection technologies - moving it from proprietary to a technology that is based on a web standard. At the same time such a change to the spec makes implementations that rely on one of the other technologies easier, since having a DOM connection between two browsing contexts means higher complexity for process-insulation browser architectures (as one example).

> I guess one disadvantage is that every device could expose a different API. This (AFAICT) essentially pushes that responsibility onto the UA? I worry a bit about trying to get different UA's to communicate to each other through MessagePort, but I'm not incredibly versed in it.

Yes, I share such a concern - but that’s not what we’re trying to achieve.

Dominik

> 
> [1] http://www.w3.org/TR/discovery-api/

Received on Wednesday, 15 January 2014 16:03:00 UTC