Re: Google/Mozilla Presentation API update

Hi Jonas, MarkF, All,

On 16 Aug 2014, at 01:00, Jonas Sicking <jonas@sicking.cc> wrote:

> This is not entirely accurate. The point of "onlyReconnect" is that
> when set to true, the UA *never* needs to get user consent.
> 
> If the page is already running, and the session id is matching, then
> clearly the user has given consent in the past and so there is no need
> to ask for consent again.
> 
> If the page is not running, or the session id does not match, then no
> session is established, an so there is no need to ask for consent
> again.

+1

>> 2) "There's a second screen available that has a pre-existing resumable session."
>> 
>> p.onavailablechange = function(e) {
>>  if (e.available && e.sessionAvailable) {
>>    // Pre-existing session found for the same origin, get the user's consent:
>>    session = p.requestSession('http://example.org/', 'foobar', /* onlyReconnect */ true);
>>    // "example.org wants to ..."
>>  } else {
>>    console.log('No resumable sessions found, do something else.');
>>  }
>> };
>> 
>> I think 2) allows easier resuming of pre-existing sessions. The names of the flags to be bikeshed :-)
> 
> However I still think like 2) makes for slightly simpler code. So it
> might still be worth using.
> 
> But I still think that we should use the semantics described above for
> onlyReconnect. I.e. when onlyReconnect is set to true the API
> guarantees that no user consent UI is shown. That is useful to handle
> the case when for example the session on the TV dies between when the
> device discover that there's a TV with a session, and the call to
> requestSession happens.

My personal preference leans toward 2) too.

>> I'm wondering if there are implementability concerns in making the PresentationSession available directly on the "presenting" page via the "session" property. For example, what would this log on the "presenting" page assuming there's a pre-existing session. Also would this call be non-blocking?:
> 
> Before anything at all can be loaded on the presenting device, the
> controlling device needs to send the URL to the presenting device.
> Once the controlling device receives the URL, it seems to me that it
> has enough information that it can create a session object.

Right.

All - it seems it would be fine also from the process perspective to continue to update the CG spec and publish an updated version of it. The improvements discussed in this thread could be landed into the updated spec.

The CG can then provide the updated spec to the WG as further input. This allows us to evolve the spec in the CG in parallel to the WG creation, and do the handover when the WG is up and running.

MarkF - feel free to contribute concrete spec updates. I’d guess Dominik is happy to help you with the tooling if he gets some PRs in turn :-)

Thanks,

-Anssi

Received on Tuesday, 19 August 2014 08:08:06 UTC