RE: Updated Presentation API WebIDL - call for review

Hi Wes, Anssi, and all,

For a "local" discovery and interaction, I totally agree with Wes.  Without
standardizing network protocols, we will be in a situation where vendor A's
TVs can only interact with vendor A's smartphones.  More realistically, a
user of vendor A's TV would have to install vendor A's UA into his
smartphone, only in a lucky case that vendor A provides the software for his
smartphone.

Best Regards,
Dong-Young Lee


-----Original Message-----
From: Wes Johnston [mailto:wjohnston@mozilla.com] 
Sent: Tuesday, March 25, 2014 1:57 AM
To: Kostiainen, Anssi
Cc: public-webscreens@w3.org
Subject: 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 Tuesday, 25 March 2014 00:33:33 UTC