Re: Updated Presentation API WebIDL - call for review

I agree that interoperability makes the Presentation API much more
powerful.  This is a worthwhile goal.

However specifying the network protocol stack to enable Presentation API
use cases is a significant task and boils down into at least four separate
protocols that need to be defined:

(1) Discovery
(2) Connection establishment and transport, including message addressing,
security and authentication
(3) Application / media control protocol
(4) Media streaming

Some of these have existing standards that can be adapted, in other cases
new standards will have to be defined from scratch, and each of them have
various tradeoffs.  In order to keep momentum on the Presentation API, I
think working towards them in a separate forum (IETF? A sub-group of this
CG?) would enable parallel progress.

m.



On Mon, Mar 24, 2014 at 5:33 PM, Dong-Young Lee <dongyoung.lee@lge.com>wrote:

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


-- 
http://wiki/Main/OnlyCheckEmailTwiceADay