Ship websockets in core

[piscisaureus]

Websockets is a standardized protocol that is core to the web. I think it should ship in core.

Discussion taking place here: nodejs/node-v0.x-archive#8005

[mscdex]

-1 WebSockets is still something better suited for userland IMHO. Sure it's something that many people do use, but there are also many other widely used standardized protocols/APIs that could be argued as "core" to the "web" that are not currently included in node/io.js core. For example: multipart parsing/generation, Server-sent events, HTTP/2, ICMP, SSH/SFTP, FTP, SOCKS, VNC/RFB, SMTP/IMAP/POP3, SOAP, Web Workers (as an API), XHR/XHR2 (as an API), etc.

The main complaint in nodejs/node-v0.x-archive#8005 had to do with an issue in node-gyp and even then the node-gyp issue was not something that affected the installation and use of the third-party module in question.

There was also a different discussion in there about the need for easily distributing compiled addons for Windows users, but as someone already noted there, node-pre-gyp already provides a mechanism for solving that problem. Maybe npm should incorporate something like that, but that's a separate topic.

[jbergstroem]

My problem with issue nodejs/node-v0.x-archive#8005 is that it grew from ws to bundling compilers. Would the crowd in that issue be happy with "just" supporting ws in core? Also, supporting ws but for instance not http2 is a pretty tough decision that probably is better to avoid unless there's a clear path forward every time the decision about what belongs in core decides to show up.

[Qard]

FYI: The ws module is pure JS now. The last bits of native stuff have been pulled out to optional dependencies. So that Windows issue isn't really relevant anymore, if people just update their dependencies.

[benjamingr]

What advantages would putting this in core offer?

[yosuke-furukawa]

+1 : websocket is implemented by core members.
-1 : websocket is in core API.

I think core module would better to keep simple. ws are a little complicated.

IMO, websocket is not core API, but websocket should be implemented by core members like readable-stream.

Golang team chooses similar strategy. They has official but not core API like these. websocket is listed in the link. spdy is also listed.

And I have a tiny concerns about einaros/ws module, the module does not have main active committers....
So, I have highly recommend core members implemented websocket as a SUB-STANDARD module.

[Qard]

I've seen the topic of "official" userland modules come up a couple times now. Perhaps it could be a topic for a future TC meeting?

[benjamingr]

I'm definitely in favour of userland official supported modules - decoupling shipments from core and modularizing code sounds like an excellent idea for io and will allow better interop and more modular code and deployment.

[tellnes]

When you are asking for official supported userland modules, then what you really is asking for is a repo under the iojs org and a WG for that project? Maybe the possibility to run project tests on jenkins?

The problem with calling those officially is that it implies some guaranty. If a official module is abandoned by its WG, what happens then?

[cjihrig]

+1 for a blessed module outside of core.

[benjamingr]

@tellnes yes - this is exactly what the point is - under the iojs org and WG. The whole point is indeed that guarantee - that it will not be abandoned by the WG and that "grown up"s give it the same LTS support as shipments get.

[Fishrock123]

I'm not sure about adding this to core. http is different. Since we already have http and have to maintain it for the long run, adding http/2 support is more reasonable as it is only maintaining an existing core module.

[piscisaureus]

What advantages would putting this in core offer?

There would be no need for compiling a native addon in order to use websockets.

[benjamingr]

@piscisaureus Does this have to be written as a native addon?

Sorry for the native question - but why can't this be implemented in (low level, closure free) JavaScript?

[piscisaureus]

BTW I'm not saying that we should put "ws" into core, although it'd be an obvious starting point for the exploration. But from an API perspective, the websockets implementation should integrate well with the built-in http(s) server, and be as simple as possible.