- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Dec 2015 11:19:39 +0000
- To: public-secondscreen@w3.org
Hi @avayvod, > Since sending and receiving messages to/from a "connecting" connection might sound confusing, and w/o this extra functionality "connecting" state doesn't add much, maybe there're other ways we could workaround passing the metadata etc? While there may be better ways to expose messaging channels, consistency across similar specs seems like a good idea. Typically, both WebSockets and WebRTC data channels have `connecting`, `open`, `closing` and `closed` ready states: https://html.spec.whatwg.org/multipage/comms.html#dom-websocket-readystate http://w3c.github.io/webrtc-pc/#idl-def-RTCDataChannelState They also both throw an error when a message is sent while the ready state is `connecting`: https://html.spec.whatwg.org/multipage/comms.html#dom-websocket-send http://w3c.github.io/webrtc-pc/#dom-datachannel-send I don't think there is any notion of message buffering in these specs either: `open` means the message can, in theory at least, be delivered immediately. The `connecting` proposal would align the spec nicely with the two other specs. The alternatives you suggest would create a different scheme which, while better in some cases, may also confuse developers used to dealing with WebSocket channels. Do we need to solve a specific case that WebSockets and WebRTC data channels do not have? -- GitHub Notification of comment by tidoust Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/214#issuecomment-165427600 using your GitHub account
Received on Thursday, 17 December 2015 11:19:46 UTC