Re: Google/Mozilla Presentation API update

On Wed, Aug 20, 2014 at 6:02 PM, mark a. foltz <mfoltz@google.com> wrote:
> 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.

Won't this still result in an object that has both a send() and a
close() function? So I don't see how it addresses your concern?

But I don't think it's a problem to have a close() function on a
channel object, even if the channel happens to be backed by something
that doesn't actually have a persistent channel. The close() call
would simply result in stopping to listen on that channel. I.e. we can
still archive the same behavior as a UNIX socket, even if calling
close() doesn't actually send any network messages, and so would
always fire onclose very quickly.

You can see that the UDP socket API defined at [1] does the same
thing, even though it doesn't actually hold a persistent channel.

But maybe I'm misunderstanding your concern?

[1] http://raw-sockets.sysapps.org/#idl-def-UDPSocket

/ Jonas

Received on Saturday, 23 August 2014 00:05:30 UTC