Re: Google/Mozilla Presentation API update

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

> 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.
>>
>
​Ok, so if multiple simultaneous connections are allowed we will need some
way to tell the presenting page when controllers come and go and which
controller each message is from, right ?

In that case, I guess there is no downside to calling requestSession()
automatically to re-establish all known prior sessions and thereby finding
our which are active. Any "single controller" application model would then
be implemented by the application.

Still, I don't think the availability filtering problem is going to go away
and I'd prefer that we address it.

...Mark​




>
>> m.
>>
>>
>