Re: Updated Presentation API WebIDL - call for review

Hi Wes,

thanks for your additional explanations - very helpful to understand your point.

On 24 Mar 2014, at 18:57, Wes Johnston <wjohnston@mozilla.com> wrote:

> I thought Jonas was going to respond to this list, but he hasn't. Sorry for my delay.
>> The “magic happens” part is an implementation detail. Under the hood, the implementation could, for example, re-use existing machinery of RTCPeerConnection, WebSockets, XHR depending on what works best for the specific case and device at hand.


> For the single UA case, I think that having this as an implementation detail is fine, but we're including two UA's here, and that will require some sort of network protocol between the two. We can write it in a separate spec, but it needs to be pointed to here explicitly at least, and implementations that don't use/honor it shouldn't call themselves spec compliant.
> 
> Without specifying it, it will fall to the UA to implement a separate network protocol for each device they "support", which will likely result in a system where only "blessed" devices are usable with a similarly "blessed" browser. That's the thing I want to avoid, but its likely where this is headed without an explicit network stack. i.e. If you want to use device-X, you'll have to switch to browser-Y

I share this concern but I also have my doubts that we can solve this problem by means of a specification. Similar to what Anssi hints at with the video codec precedence: What are the limits of leverage or pressure that a spec can exert on the browser implementations?

I see this boil down to: There would likely be several browsers implementing several different connection mechanisms to second screens. For example wired connections (through Mobile High Definition Link, Slimport, HDMI, DVI...), Miracast, Airplay, just RTSP streaming - and Chromecast, which is a somewhat special case because of the two UA situation, but I would count it as a connection technology still.

> […] To actually work with another UA, I need to specify how a browser would:
> 
> 1.) Detect me
> 2.) Negotiate a connection
> 3.) What the data we're transferring over that connection looks like.


In this way, your suggestion would translate to: Let’s have one separate specification which defines an open connection technology that every browser has to implement. This could be video stream based, where the remote device just receives a passive stream, or one level higher - some sort of standardized inter-UA link. Let’s assume we define such a spec and include it as a requirement for Presentation API: What are the chances of all vendors implementing it?

I think this is a situation where we have to accept certain market realities. I am not saying we couldn’t try this, but how about bringing second screen usage scenarios to the web now, based on the devices, connection technologies and protocols that are available and deployed as of today - then possibly extend this with an optional specification that brings in devices that adhere to this additional spec/requirement.

One of the possibly "more open” or more interoperable backends that could be spec’ed would be a DLNA-based implementation where the UA sends a video stream to nearby DLNA renderers. Alternatively, more simply, one could just configure a UDP destination address in the browser that the UA sends a video stream to. 

In any case, I think there’s not enough leverage to make any specific connection technology mandatory. In my opinion, the maximum we can achieve is to recommend this as an additional connection backend, it cannot be practically enforced.


> We also talked a bit here about how, even in the single UA case, UA's will need to explicitly use separate cookie's/localstorage/etc for each "window" in order to provide a consistent experience with the dual-UA case. I haven't seen much of that come by here, but its possible I missed the messages.

That’s a good point, which we should add to the API Discussion Wiki page and keep it there as an open item. As you say, one solution is to keep the secondary window in a separate session realm / like in a way incognito/private browsing mode.


To sum up, in line with the group charter I suggest for the group to:

- define an API that brings second screen usage scenarios to the Web now, based on the devices, connection technologies and protocols that are available and deployed as of today
- possibly extend this with an optional specification that brings in devices that adhere to this additional spec/requirement

Please let us know if you see concerns with this approach,

Dominik

Received on Tuesday, 25 March 2014 11:16:30 UTC