W3C home > Mailing lists > Public > public-secondscreen@w3.org > December 2015

Re: [presentation-api] Add a "starting" state to PresentationConnection

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Thu, 17 Dec 2015 11:19:39 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-165427600-1450351178-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Thursday, 17 December 2015 11:19:47 UTC