Re: Presentation API changes proposal

Thanks for prompt replies, everyone. Comments/answers inline:

On Thu, Jan 9, 2014 at 3:33 AM, Mark Scott <markdavidscott@google.com>wrote:

> I agree with Dominik's comment that having an event-based way to detect
> device availability vs. relying on polling is important.  It's actually
> quite common for target devices to be transient (e.g. the case of turning
> on a TV), and responsiveness is important here since most sites will likely
> not show any UI related to presenting on a secondary display unless a
> display is known to be available.
>
> One other comment is that it would help to clarify the scope of "session
> in progress".  There are two relevant variations of this:
> - Providing access to a session started by the local UA after a page
> navigation/refresh.
> - Providing access to a session after a UA restart, or started by a
> different UA (with some check for origin, of course).
>
> The latter can be surprisingly important; being stuck in a state where
> something is being shown with no clear way to control or stop it is a
> highly problematic use case.
>
> The "different UA" variation is relevant for similar reasons, e.g. my
> primary device ran out of battery, so I'm switching to an alternate device.
>  I mention it in passing as I think the complexity of solving this case in
> a general way may be impractically high.
>
> Mark.
>
>
> On Wed, Jan 8, 2014 at 7:17 AM, Rottsches, Dominik <
> dominik.rottsches@intel.com> wrote:
>
>> Hi Anton, Miguel, Peter,
>>
>> welcome to the CG - good to have you guys joining! And thanks for your
>> detailed feedback and change proposals.
>>
>> On Tue, 2014-01-07 at 16:10 +0000, Anton Vayvod wrote:
>>
>>
>> > 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.
>>
>> Yes - maybe let's clarify the terms a bit. I think the main distinction
>> is the feasibility of implementing the API with either one or two user
>> agents, or keeping it open to be implementable in both ways.
>>
>> With Google's Chromecast background, I can see your interest in editing
>> the spec in a way that does not make a single UA solution obligatory.
>>
>> Even assuming a single UA implementation, I would perhaps not call the
>> functionality "mirroring", since the single UA can prepare different
>> rendering output for the first window and the presentation window.
>>
>
Yes, we meant "mirroring" implementation-wise, e.g. rendering the
presentation window via the local UA and sending the frames to the remote
display vs. rendering the presentation window on a separate UA.


>
>> > 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.
>>
>> That is a useful feature, I think. It's also in line with what Dean
>> Jackson from Apple was suggesting during the TPAC session: We should
>> keep in mind that the destination devices may have considerable
>> computing power - so it seems quite straightforward to give them a
>> chance to run standalone.
>>
>> > 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.
>>
>> This sounds like a good idea to me.
>> In addition to the questions that Anssi raised, I would suggest:
>>
>> Perhaps we can tweak the naming. Something like "stayAfterUnload",
>> "persistent",
>> "persistAfterUnload" or similar.
>>
>> To avoid the boolean, we could pass an options object, which
>> would later allow other constraints on display type, resolution or
>> similar, as some people suggested during TPAC.
>>
>> Promise requestShow(optional DOMString url = "about:blank",
>>                     optional PresentationOptions)
>>
>> with an options object like:
>>
>> options = { persistent: true };
>>
>
Agree. I like this idea.


>
>> > 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.
>> >
>> >
>> IMO it's a clever idea to query by URL for display availability. It
>> combines the availability of storing the user's preference/previous
>> allow/reject decisions with querying for existing sessions according to
>> your proposal above.
>>
>> However, could you explain a little more what this URL here represents:
>> Is this the same URL as in requestShow, i.e. a "remote screen app" page
>> location href? Or is this URL more used in the sense of an application
>> or organization identifier and does not actually point to a document?
>>
>
We thought of this as the same URL as in requestShow to make things simpler
- the developer only needs to think about one exact URL - and more
Chromecast-agnostic since it's not some proprietary application id. We felt
that allowing some custom URI schemes like cast://applicationId instead of
the URL would be too specific to Cast protocol only.


>> Would there be some cross-origin restrictions on what the URL can be? Or
>> could we strip the url parameter and use the primary page's
>> document.location.href as the query parameter/reference?
>>
>
On one hand, there must be some protection from third-party developers
abusing someone else's receiver. On the other hand, I can imagine some
basic generic player available for everyone to play media URLs. Maybe we
should add some mechanism for the receivers to specify allowed origins?


> Would the primary page have to call this function periodically to see
>> displays going away? That's perhaps not the most elegant way to find
>> out about a Chromecast or a Miracast display going offline, or changing
>> subnet for example.
>>
>
You're right. Would we need a property like
navigator.presentation.displayFllter to pass the player URL to the UA
before the search for available displays starts? Peter had objections to
displayAvailable being a synchronous property. Perhaps, change it to be a
Promise but leave the event handler to receive updates?


>> > 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.
>> >
>> In my opinion that is a good direction to decouple the UAs here and
>> allow single or dual UA implementations.
>>
>> It has a couple of implications though, which we need to solve:
>>
>> What we get with WindowProxy:
>> - If we return a WindowProxy we can use
>> Web Messaging in a straightforward way. We can just call
>> seconScreen.postMessage(...) and inside the page on the secondary
>> screen we can add an event listener to the message event / assign an
>> onmessage handler.
>> - We have an onunload event, at least for pages that
>> are opened from same origin.
>>
>> Unfortunately, MessagePorts do not have onclose events anymore.
>>
>> Now, if we change this to let's say the following object as the result
>> of the Promise returned from the call to requestShow():
>> PresentationWindow {
>>    EventHandler onclose;
>>    MessagePort port;
>> }
>>
>
Yes, our thinking is to enhance MessagePort with necessary additions rather
than have to implement the full Window object part of which won't be
meaningful in terms of the presentation display.


>
>> We would have such an onclose event and we have communication from
>> primary page to the secondary one. But where does the other end of the
>> MessagePort go, where does it surface on the presentation window end?
>>
>> One possibility is to add another event "onconnected" or similar to the
>> navigator.presentation object and deliver a MessagePort there? This
>> event would fire only on pages that are opened as "receiver
>> applications" in Chromecast terms. And this page's onunload would
>> correspond to the PresentationWindow's onclose for example.
>>
>
Sounds good. In case of different UAs though, the receiving end might be
implemented differently. Chromecast, for example, provides its receiver SDK
to use by the receiver applications. The UA hosting the controller would
transform MessagePort events into Chromecast events and send it towards the
device that would forward it to the player in some form.


>
>> Looking forward to hearing thoughts and suggestions, especially on how
>> to solve those issues in the previous paragraphs,
>>
>> Dominik
>> >
>> >
>> > [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
>>
>>
>