So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see that...

sneak · on Nov 28, 2012

It's not TCP over HTTP, that would require a TCP stack. It's the io bytestream from a specific TCP connection, shuttled over HTTP.

It's not entirely bogus, just mostly so. I really dislike this whole "the internet == the web" way of thinking, though.

javajosh · on Nov 29, 2012

On the contrary, this sort of things allows us to write clients in a uniform way. It will be nice to be able to debug the redis client in a jsfiddle. :)

sneak · on Nov 29, 2012

By this argument, "uniformity" means we should then port the linux kernel to javascript so that we can debug it in jsfiddle.

Down that path lies madness.

javajosh · on Nov 29, 2012

What's wrong with writing a kernel in JavaScript? This would actually be quite valuable as a pedagogical tool.

icebraining · on Nov 28, 2012

It uses Websockets, which are only HTTP for the handshake: the rest of the connection is just a TCP stream.

So it's really more like a NAT bridge.

khakimov · on Nov 28, 2012

it's not about pure tcp, as i get it - it allows you communicate from browser directly (via webtcp server as a bridge) with any servers such as redis, mongodb, rabbitmq and so on.

WebBrowser --- data ---> WebTCP bridge (translate data to servers) --- data ---> redis/rabbitmq/any_tcp(and i think udp also possible?)_server_even_smtp

yankoff · on Nov 28, 2012

Well, you didn't read the post apparently and only a title :(

chewxy · on Nov 28, 2012

I actually did. I was quite interested in the redis example. For about 10 seconds, which I then went "wtf is this useful for?"

We really need to stop reinventing the wheel

yankoff · on Nov 28, 2012

What would you use to achieve the same thing with Redis?

sebastianmck · on Nov 28, 2012

The XY Problem http://www.perlmonks.org/index.pl?node_id=542341

lttlrck · on Nov 28, 2012

REST is far more appropriate for databases.

Pub/sub is well catered for by socket.io (websockets).

This glue belongs on the server.

If I did need arbitrary TCP connections my first thought would be a websocket proxy...

chewxy · on Nov 28, 2012

I wouldn't. I'd make a HTTP call to the server, and let the server handle it. (i.e. your "what's so different from the backend method")?

yankoff · on Nov 28, 2012

Yep, and i wrote about differences to such approach in the post. Don't get me wrong, this is definitely a hack, I'm not saying people should stop doing it the old way.

chewxy · on Nov 28, 2012

Likewise. While I appreciate the concept of a bridge (I'm a strong believer that the fastest app is the app that does practically nothing at all, and I can see the benefit of using a TCP-bridge like thing to make something faster), I just think we should not be reinventing the wheel.

That is to say, if you need a TCP connection to any server, you probably should not be implementing it over HTTP (well, this is where definitions get difficult, since you know, HTTP is technically TCP. Fuck)