Websockets with web interface

[dariusc93]

Is there a more manageable way to setup websockets within a web interface?

[s-ludwig]

Hm, I thought that a convenient way had already been implemented at some point (with making a web interface method like void getWS(WebSocket socket) { ... }). But the code is obviously not there. You can consider this as a planned feature, though.

BTW, if you have anything where I didn't reply yet, feel free to ping me. I didn't get to read my GitHub notifications and forum messages from roughly October to early February,

[dariusc93]

Thank you for your reply. I try to avoid pinging unless i feel I need too (when urgent that is)

[etcimon]

I think this would quickly become deprecated, with HTTP/2 around the corner we're about to revive "long polling", because connections are now simply different "streams" living inside a single TCP Connection. The "long poll" would be a sleeping vibe.d Task in this case, with the same protocol overhead no matter how many of them are present. You can have a TaskPool of 5 long polling HTTPServerRequests and it remains very lightweight, so you can keep serving your pages using (HTTPServerRequest req, HTTPServerResponse res).

Also, although HTTP/2 is a one-way protocol (client->server or server->client), I'm adding a feature that allows to switch the direction (for RPC), giving a server the ability to become the client, and a client to become a server even though it's behind NAT & firewalls. The client can then start another HTTP2Connection and have both, a client and server HTTP2Connection with support for unlimited concurrent streams (HTTPClientRequest, HTTPServerRequest) under a single TCPConnection, using the regular vibe.d request handling syntax.

[s-ludwig]

Implemented by 41bdae6.

@etcimon: True about the HTTP/2 streams, but the world will change slow enough that people will surely still want to use this for a while. It has also been a really simple implementation, so why not.

[etcimon]

Yeah HTTP/2 is being adopted very slowly according to recent statistics. But wow, I totally forgot I had had this idea. I was imagining a client stream that can interchange its role with a server (to become another HTTP/2 server over a single HTTP/2 stream, but behind a firewall). I ended up concluding that polling on multiple streams simultaneously would do just fine to avoid latency, but I'm sure someone will end up implementing it eventually.