Re: Updated Presentation API WebIDL - call for review

Hi Wes,

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.

No problem, thanks for coming back to us.

>> 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

Thanks for elaborating this, now I see your point.

It sounds like you’ve put some thought into this, which is great. Could you write down a strawman proposal how you’d envision this to work so that the group could look at the proposal? It does not need to be anything polished, just a bit more meat to it so people can have something more concrete to play with, to have a constructive discussion here.

I hear that the single UA case is the low hanging fruit that we as a group are reaching rough consensus on, while the two UAs requires more work and especially input from participants who thing the current proposal is not fit for the task.

> I realize that some things exist in the wild already that aren't going to support this. Most (ALL) of them I know about are screen mirroring technologies that would be accessed through a single UA system anyway (i.e. there is no networking stack to worry about, although there are other things). Even with a networking stack specified, I realize that some manufacturers will likely institute black/white lists of supported devices/browsers to try and force people into their ecosystems. But at the spec level, I think we need something that provides an interoperable way forward.

Our highest priority should be interoperability. That said, I think we can draw some parallels to how HTML5 video happened. The codecs were left out of the HTML5 spec. I’m not taking sides on that one, just pointing out that there’s precedence in letting the market decide.

>> I’d like to understand what are the concrete problems that would need to be addressed you refer to above, and from which use cases those requirements are derived from.

> I'm not sure how to clarify this a whole lot more. Say I'm a garage entrepreneur. I'm developing a display that has a built in UA. I want any browser to be able to connect and work with me through the second-screen API. I can implement what we've written now, but I'm still just talking to myself. 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.

This is perfectly clear, thanks.

> 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.

Could you elaborate this a bit? This sounds like something we should definitely discuss in this group too.

Thanks,

-Anssi

Received on Tuesday, 25 March 2014 08:33:16 UTC