Re: Presentation API changes proposal

Replying to this email separately since it didn't get into the Dominik's
reply:


On Wed, Jan 8, 2014 at 10:46 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi Anton,
>
> On 07 Jan 2014, at 18:10, Anton Vayvod <avayvod@google.com> wrote:
>
> > Dear all,
> >
> > Even before Google joined the Second Screen Presentation Community
> Group, we had been closely following the development of the Presentation
> API[1].
>
> I’m happy to see you and other Googlers join the group. Welcome!
>
> > 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.
>
> Thanks for your detailed feedback. Generally, your proposal looks good to
> me considering the use case. Some comments below.
>
> > 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.
>
> I guess there would be no prompt only if there already exists a session
> identified by an url and infinitePlay is set to true? Am I right that the
> infinitePlay flag controls whether the media will continue to play even if
> the browsing context from which the requestShow() was called is destroyed?
>

Yes. We may step further and decide that the controller is always
responsible for closing the presentation window onunload if it can always
reconnect to the existing session. Then the flag would not be necessary
though some extra work would be needed from developers using the API for
the same UA rendering (to close the second screen window and to reconnect
to it if the controller crashes/navigates/reloads).


>
> The step 4 of the /algorithm to request access to the presentation
> display/ currently says:
>
> [[
>
> * Prompt the user's permission or check that the setting for allowing
> access to a presentation display enabled. If no permission is given, jump
> to the step labeled failure below. If the user never responds, this
> algorithm will never progress beyond this step.
>
> ]]
>
> We may need define a "check that the setting for allowing access to a
> presentation display” process (should make the name more concise), and
> clarify this detail in it. Also some other steps may need to be adjusted a
> bit. Do you already have a concrete proposal in mind how you’d like to
> change the algorithm?
>

No, we haven't thought about the exact wording change yet. I think the user
will have to allow the controller origin to launch/connect to a particular
URL on each presentation display and the UA will remember if the user
granted the permission (so we can allow foo.com to launch/connect to
foo.com/play on display A but not anything on display B or
boo.com/presenton device A). Or maybe it doesn't make sense to grant
permissions per
displays?


>
> Btw. How in the flinging use case you’d identify a session? Is the url
> enough (e.g. use a query string and/or fragment identifier to conveying the
> session information), or is something else required? For example, how about
> a use case where a video from the same url is being played on two separate
> secondary displays?
>

The URL of the receiver page should be enough. All additional information
about the existing session is passed back to the controller when it
connects over the MessagePort. In the example you provide, this would be
two separate sessions, at least for flinging. Could you elaborate on the
example? Do you mean that the UA might want to render the second screen
content once and then present it on both displays?


>
> > 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.
>
> In addition to making the API more future-proof, this would actually be a
> requirement for the flinging use case to work if I’m not mistaken? There
> must be a means to filter the search with an url that identifies a session
> (if enough to identify a session, that is).


Correct. The URL also allows to filter second screens out: Chromecast only
supports a whitelist of URLs, smart TVs might only allow launching YouTube
or Netflix but not foo.com while rendering locally would allow any URL.


> Other than that, this seems to be functionally-equivalent with the current
> design.
>

Except for the polling situation described by Mark and Dominik. I think the
event handler is the right way to do it.


>
> > 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.
>
> Do you have more details to share on how you’d propose the MessagePort to
> be extended?
>

I think Dominik presented a good example in his reply. We'd have an
additional onclose event.


>
> > 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!
>
> Thanks for the great feedback! I’m sure Dominik will chime in with his
> editor hat on soonish.
>
> Thanks,
>
> -Anssi
>
> > [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
>
>