Re: Google/Mozilla Presentation API update

Jonas,

Thanks for posting a more complete messaging API.

I am wondering if we need to reflect the fuller socket semantics in the
Presentation API or only ensure that network serializable types are
compatible.  For example, the channel may be backed by a cloud service that
does not have the same open/close semantics as a UNIX socket.

Here is what I had in mind.

partial interface SerializableChannel {
   void send((DOMString or Blob or ArrayBuffer or ArrayBufferView) data);
   attribute EventHandler onmessage;
}

interface PresentationSession : SerializableChannel {
  readonly attribute PresentationSessionState state;
  void close();
  attribute EventHandler onstatechange;
}

The lifetime of the channel would be controlled/reflected by the object
that implements it, in this case, the PresentationSession and its state
attribute.

m.


m.


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