Re: Updated Presentation API WebIDL - call for review

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

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.

Thanks,
Wes

Received on Monday, 24 March 2014 16:57:35 UTC