- 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