W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

Re: [presentation-api] Rethinking availability monitoring

From: Mark Watson <watsonm@netflix.com>
Date: Wed, 13 May 2015 17:54:27 -0700
Message-ID: <-6222187503927788119@unknownmsgid>
To: Matt Hammond via GitHub <sysbot+gh@w3.org>
Cc: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
On May 13, 2015, at 11:45 AM, Matt Hammond via GitHub <sysbot+gh@w3.org> wrote:

>> The Promise resolves when the browser has an answer to the query
> (not necessarily when the underlying system changes state). Since
> answering the question of "are screens available" likely involves
> cross-process or cross-device communication, using a Promise frees up
> Javascript execution while the browser figures that out.
>>> I think the only sensible behaviour is for the promise to resolve
> only if there is availability (not unavailability).
>> Suppose there are no screens available; this means that the browser
> would have to monitor continuously while that Promise is pending. This
> ends up being the same as adding an event handler to
> onavailablechange to monitor all availability changes.
> Thanks for the explanation. I understand the intended behaviour now.
> I would suggest that the method returning the promise be named
> something such as `checkAvailability` or `determineAvailability`. For
> me, `getAvailability` implies a passive retrieval of some kind of
> state information and led me to my previous conclusions.
>> I think the params are intended to communicate to the user agent
> additional requirements for the remote screen (yet to be determined).
> For passing information to the remote presentation there are plenty of
> ways to use URLs: query parameters, URL fragments, or messaging after
> the presentation is connected.
> Yes, this is what I had in mind. Parameters needed in the process of
> establishing availability and/or starting/joining the session.
>> Perhaps @avayvod can clarify the use of parameters (and show some
> examples)?
> I can offer some strawman examples for that would be useful for an
> implementation that can launch applications on an HbbTV 2.0
> television/set-top-box:
> * `hbbtv.appId` (integer) and `hbbtv.orgId` (integer) ... necessary to
> allow the presentation to combine itself with broadcast content
> * `hbbtv.appEndpoint` (string) ... needed to establish the
> communication channel.

Another application would be for the page to specify the DIAL
application or applications it wishes to interact with. This needs to
be provided ahead of availability monitoring so that the UA can filter
out devices that do not support that application.

> --
> GitHub Notif of comment by matt-hammond-bbc
> See
> https://github.com/w3c/presentation-api/issues/81#issuecomment-101772960
Received on Thursday, 14 May 2015 00:54:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:54 UTC