Re: Google/Mozilla Presentation API update

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;
};


> 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).

/ Jonas

Received on Thursday, 21 August 2014 00:05:48 UTC