- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 22 Aug 2014 17:04:32 -0700
- To: "mark a. foltz" <mfoltz@google.com>
- Cc: Mark Watson <watsonm@netflix.com>, Anton Vayvod <avayvod@google.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Marco Chen <mchen@mozilla.com>, Wesley Johnston <wjohnston@mozilla.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Evelyn Hung <ehung@mozilla.com>
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