Re: Google/Mozilla Presentation API update

Correction to my earlier post in bold:

I think negotiation of the active controller would happen at a level above
the connection status of individual pages to the presentation.  Meaning,
the application could implement a leader election protocol using the
messaging channel, and message *to the losers* to close their connections
(or assume a passive role).

m.

My assumption is that the presenting page allows simultaneous connection
from multiple controlling pages.  The spec does not seem entirely clear on
when the PresentationSession transitions between connected to disconnected,
and we'll have to tighten that up to support reconnection and multiple
controlling pages.

On Wed, Aug 20, 2014 at 5:42 PM, mark a. foltz <mfoltz@google.com> wrote:

> On Wed, Aug 20, 2014 at 5:10 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>>
>> On Wed, Aug 20, 2014 at 5:04 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>>> On Wed, Aug 20, 2014 at 4:47 PM, Mark Watson <watsonm@netflix.com>
>>> wrote:
>>> > Regarding the API for message passing, wouldn't something simpler like
>>> a
>>> > subset of the WebSocket API be sufficient ?
>>>
>>> The messaging subset of RTCDataChannel is effectively the same as the
>>> messaging subset of WebSocket. This is coincidental since
>>> RTCDataChannel intentionally tried to have the same messaging API as
>>> WebSocket.
>>>
>>> So what we should do is to have an object with the following interface:
>>>
>>> interface PresentationAPISocketChannelWithATwist {
>>>   // The twist is that it's both a socket and a channel.
>>>
>>>   void send((DOMString or Blob or ArrayBuffer or ArrayBufferView) data);
>>>   void close ();
>>>
>>>   attribute BinaryType binaryType;
>>>   readonly attribute unsigned long bufferedAmount;
>>>   readonly attribute ?? readyState; // unclear which one we should
>>> follow.
>>>
>>>   attribute EventHandler onmessage;
>>>   attribute EventHandler onopen;
>>>   attribute EventHandler onerror;
>>>   attribute EventHandler onclose;
>>> };
>>>
>>
>> ​Looks great.​
>>
>>
>>>
>>>
>>> > Regarding restarting sessions, don't the proposals suffer from the same
>>> > problem of available device detection that the original API suffers
>>> from ?
>>> > That is, the onavailablechange event is indescriminate and even if it
>>> is
>>> > fired a call to requestSession may fail (no available devices /
>>> sessions
>>> > matching the parameters to the requestSession call). This corresponds
>>> to a
>>> > UX where the "present" icon is shown, but clicking it results in a
>>> failure.
>>> > There's no need for this bad UX, because we know, before showing the
>>> icon,
>>> > everything we need to know to make it more accurate.
>>>
>>> No. The page would simply call requestSession() with resumeOnly set to
>>> true before displaying any UI. If the connection succeeds the page
>>> would display the "connected" UI rather than a "present" icon. If the
>>> connection fails, then it would show a "present" icon (unless the
>>> onavailablechange fires again and lets the page know that the TV is no
>>> longer available).
>>>
>>
>> ​I can see how that works, but what if the site doesn't want to
>> automatically reconnect​ ? Suppose the presentation id has been shared
>> across a bunch of devices but the application model is that there is only
>> one active controller at a time ? Reconnecting would correspond to wresting
>> control from the existing controller, which the user might not want.
>>
>
> I think negotiation of the active controller would happen at a level above
> the connection status of individual pages to the presentation.  Meaning,
> the application could implement a leader election protocol using the
> messaging channel, and message to close their connections (or assume a
> passive role).
>
> My assumption is that the presenting page allows simultaneous connection
> from multiple controlling pages.  The spec does not seem entirely clear on
> when the PresentationSession transitions between connected to disconnected,
> and we'll have to tighten that up to support reconnection and multiple
> controlling pages.
>
> m.
>
>