- From: Mark Watson <watsonm@netflix.com>
- Date: Tue, 3 Jun 2014 08:46:08 -0700
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Cc: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Mark Scott <markdavidscott@google.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "mark a. foltz" <mfoltz@google.com>, Bob Lund <B.Lund@cablelabs.com>, Philipp Hoschka <ph@w3.org>, Daniel Davis <ddavis@w3.org>
- Message-ID: <CAEnTvdCZYw1mPb6sP3X4=FK36=+581W0oaLLnZka87yW5cYw+Q@mail.gmail.com>
On Tue, Jun 3, 2014 at 2:39 AM, Kostiainen, Anssi < anssi.kostiainen@intel.com> wrote: > 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. > The point is that we should not show the user the "cast/fling/present" icon *at all* if there are no suitable screens available. We certainly can't do a presentation attempt (showing the user a display list, and then possibly succeeding and showing some content on the remote screen) just to find out whether to show this icon or not! When the user clicks the icon, then we call requestShow() and the user chooses from the available screens. At this point, the UA can certainly filter screens based on whatever mechanisms it chooses and exact knowledge of the URL to be presented. The user could choose a screen at this point and it could still fail. But the two things we don't want the UA to do are: (1) put screens in the list that the UA knows will fail (e.g. a screen with only a YouTube app when the URL is a Netflix URL) (2) show an empty list My suggestion is just to give the UA the information it presently gets in requestShow() earlier. The UA follows the same algorithm it would for requestShow() to determine the list of displays - whatever algorithm that is - and only fires the onavailablechange event if the list is non-empty. We could, equivalently, though rather awkwardly, have a new method: isListOfDisplaysEmpty( <url> ) which would return true or false after following the same algorithm that requestShow() does for determining the list of screens to show the users. Then the site could suppress the icon when this method returns true. But, still, I think it better to integrate this aspect into the API proper as I proposed. ...Mark > > 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 15:46:40 UTC