Re: Google/Mozilla Presentation API update

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.

...Mark



>
> / Jonas
>