Filtering out non compatible displays (was: Draft of Second Screen Presentation Working Group Charter available)

Hi MarkW, All,

On 30 May 2014, at 18:00, Mark Watson <watsonm@netflix.com> wrote:

> what is the value of the input parameter in presentation.requestScreens(…)?
> 
> ​With this information, the UA can filter out screens that could not render that URL. For example, if the URL is www.netflix.com and the UA detects a device using DIAL that does not have the Netflix app, the presence of that device alone would not trigger the onavailabilitychange event.​ Of course if there is another device with the Netflix app, or if there is a second screen connected via MirraCast etc., that can render any URL, then the event would fire.

If the group wishes to go down this path, I feel that something more explicit would be better, along the lines of the isScreenAvailableFor() proposal by Francois [1], or something like canShowType(), modelled after the canPlayType() [2].

However, I’m not sure that such a mechanism is the right way to solve the problem at hand, as developers would not be able to rely on it for real. We’d end up returning something vague similar to canPlayType (“maybe”, “probably”) and that would not help us solve MarkW’s use case AFAICT.

The best way to figure out if something works on the Web is to try and see what happens, and have a good fallback strategy in place. IOW, invoke requestShow(), and see if the request fails or not, and act accordingly. Even if the UA could technically understand the resource, the end user could deny the request, the second screen could be disconnected in between the canShowType() and requestShow() etc. and these error cases would need to be handled by the web developer anyway if she wishes to provide a good user experience.

Specifically, the canPlayType() has various known interop issues, and if we’d be following a similar path in this group we’d inherit the same issues and likely more, as we’d need to query multiple, potentially remote, devices for their ability to support the given resource.

This is what the draft charter says currently:

[[

The API will provide a means to identify whether requesting display on a second screen is likely successful, i.e. whether at least one secondary screen is available for display.

]]

To clarify expectations: even if this is in the scope of the charter, it does not mean the group will necessarily ship an API with this feature. The charter gives us the boundaries within which to play. If the feature is unable to pass the interop phase, then this feature will be dropped.

All - please let us know if you have ideas how to solve MarkW’s use case, or if you have suggestions how for rewording the above text in the charter to clarify this.

Thanks,

-Anssi

[1] http://lists.w3.org/Archives/Public/public-webscreens/2014May/0058.html

[2] http://www.w3.org/TR/html5/embedded-content-0.html#dom-navigator-canplaytype

Received on Tuesday, 3 June 2014 09:39:56 UTC