Re: Presentation API changes proposal

The way I look at this is that MessagePort with enhancements is merely used
to communicate between the sender web page and the sender UA and between
the receiver UA and the receiver page. What happens between the UAs is not
specified and left for the browser vendors to choose and implement.

Our objection to using WindowProxy instead is merely out of practical
reasons: the interface is much bigger and browser vendors will have more
methods to implement and support. MessagePort with onclose event handler
seems much more lightweight and should still provide enough functionality.


On Fri, Jan 10, 2014 at 9:28 PM, Wesley Johnston <wjohnston@mozilla.com>wrote:

> > Could you please elaborate on what in particular you worry about?
>
> Communications between two different vendors always seem to get hairy, and
> I didn't see anything in the Message port specs talking about cross-UA
> communication as a goal (but I'm still reading through it). My first
> thought was just that the WebMessaging problem is already solved via
> PeerConnection.
>
> - Wes
>
> ----- Original Message -----
> From: "Anton Vayvod" <avayvod@google.com>
> To: "Wesley Johnston" <wjohnston@mozilla.com>
> Cc: public-webscreens@w3c.org, "Miguel Garcia" <miguelg@google.com>,
> "Peter Beverloo" <beverloo@google.com>
> Sent: Friday, January 10, 2014 11:13:47 AM
> Subject: Re: Presentation API changes proposal
>
> There were some big concerns about the Network Service Discovery API in
> response to the Intent to Implement in the Blink community[1], esp. about
> its security and privacy. It also feels too low-level, e.g. it explicitly
> defines the discovery protocols: SSDP, Zeroconf and DIAL.
>
> Presentation API on the other hand is much more generic: it allows to
> establish a communication channel between two entities responsible for
> content rendering on two displays whether within the same UA or between two
> UAs. Could you please elaborate on what in particular you worry about?
>
> [1]
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM
>
>
> On Fri, Jan 10, 2014 at 7:00 PM, Wesley Johnston <wjohnston@mozilla.com
> >wrote:
>
> > I'm curious, what does this second UA proposal solve that isn't already
> > covered by the Network Service Discovery API [1]? It looks like it would
> > provide enough information to detect a second UA device on the network,
> > along with the ability to communicate with the device (or you could set
> up
> > a peer connection).
> >
> > I guess one disadvantage is that every device could expose a different
> > API. This (AFAICT) essentially pushes that responsibility onto the UA? I
> > worry a bit about trying to get different UA's to communicate to each
> other
> > through MessagePort, but I'm not incredibly versed in it.
> >
> > - Wes
> >
> > [1] http://www.w3.org/TR/discovery-api/
> >
> > ----- Original Message -----
> > From: "Anton Vayvod" <avayvod@google.com>
> > To: public-webscreens@w3c.org
> > Cc: "Miguel Garcia" <miguelg@google.com>, "Peter Beverloo" <
> > beverloo@google.com>
> > Sent: Tuesday, January 7, 2014 8:10:33 AM
> > Subject: Presentation API changes proposal
> >
> > Dear all,
> >
> > Even before Google joined the Second Screen Presentation Community Group,
> > we had been closely following the development of the Presentation API[1].
> > We would like to propose some changes to the specification in order to
> > allow not just mirroring technologies to be built on top of it, but also
> > allow media flinging technologies (like Chromecast, [2]). In that case,
> one
> > user agent triggers and controls the content on the second screen, while
> a
> > second user agent displays the content and responds to the commands it
> > receives.
> >
> > This would have some implications on the API itself: it would become
> > possible for media to continue playing, even when the user agent that
> > triggered it is killed, for example because the associated tab has been
> > closed. Because of that, we would also need to be able to connect to
> > already in-progress sessions.
> >
> >
> > With that in mind, the first change we would like to propose to the API
> is
> > as follows:
> >
> > Promise requestShow(optional DOMString url = "about:blank", optional
> > boolean infinitePlay = false); [3]
> >
> > Calling requestShow with a url of a session in progress would return the
> > WindowProxy (or MessagePort) of the session in progress instead of
> > prompting the user.
> >
> >
> > On top of this change, we’d also like to explore two other things that
> > would make the API easier to implement and use.
> >
> > Promise searchSecondScreens(optional DOMString url);
> >
> > This would replace displayAvailable and onDisplayAvailableChange. The
> > promise would return true if there is at least one display available for
> > this url. The implementation of the method can certainly cache devices
> and
> > keep a similar displayAvailable + event handler mechanism internally.
> >
> >
> > Finally we’d like to change the spec so that the Promise object can
> return
> > a small wrapper over MessagePort instead of a WindowsProxy. Implementing
> a
> > full WindowsProxy will add additional and unnecessary complexity, making
> > browser implementations harder without a need.
> >
> >
> > Please do let us know if these changes sound too dramatic or unfeasible.
> We
> > are completely open to ideas and would be happy to be involved in further
> > discussions!
> >
> > Best Regards
> >
> > Miguel, Anton and Peter
> >
> > [1] http://webscreens.github.io/presentation-api/
> > [2] http://www.google.com/intl/en-GB/chrome/devices/chromecast/
> > [3] http://dom.spec.whatwg.org/#promises
> >
>