Re: Draft of Second Screen Presentation Working Group Charter available (was: Heads-Up: Plan for Working Group on Second Screen Presentation)

On Fri, May 16, 2014 at 12:22 AM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> Hi MarkW,
>
> > In "API and associated specification", where we say "An API to allow a
> web application to request display of web content on a connected display,
> with a means to communicate with and control the web content from the
> initiating page and other authorized pages", I think we should explicitly
> add something like "and a means to discover when a display capable of
> rendering the web content is available".
> >
> > This is the major requirement that is not presently supported by the API
> draft: there is no way at present for the web page to determine whether it
> should render the icon that shows the user a capable display is available
> (and we have decided it should be the page that renders that icon, not the
> UA).
>
> Note that the API draft [1] supports this:
>
>   presentation.onavailablechange = function(e) {
>     showButton.disabled = !e.available;
>     showButton.onclick = show;
>   };
>
>
​Hi Dominik,

No, that API doesn't support the requirement I described.

As the API stands, a website would be informed of availability of all
second screens that the UA detects, independent of their capability. The
onavailablechange function is called before the site has had a chance to
inform the UA about the content types or URLs that it may wish to render.

So, for example, if the site is www.youtube.com and the UA supports DIAL
and discovers a TV with the Netflix application, onavailablechange would be
called, but when requestsession was called with a youtube.com URL, there
would be nothing the UA could do with that.

Or, equally, the only device discovered is a picture frame which cannot
show video (if we want to support devices restricted by content type, that
is).

What we need is something more like:

interface DiscoverScreens
{
    Screens discoverScreens( optional DOMString? url-pattern = null,
optional DOMString? content-type = null );
};

interface Screens
{
   attribute EventHandler onavailablechange;

   PresentationSession requestSession( DOMString url );
};



> I agree that we should add the sentence you’re suggesting. We should then
> incorporate the availability information concept into the use cases section
> of the API discussion as well.
>
> Dominik
>
> [1] https://www.w3.org/community/webscreens/wiki/API_Discussion


​Yes. It was supposed to be covered by the "Flinging" use-case but I see
now that doesn't incorporate all the concepts from the input (
http://lists.w3.org/Archives/Public/public-webscreens/2014Jan/0000.html).


...Mark​