
Erlang Creator Joe Armstrong Wants to Ditch AJAX, Loves Chrome's New Web Sockets - xanados
http://groups.google.com/group/erlang-programming/browse_thread/thread/a73efebabf352d19#
======
axod
I've just completed implementing WebSocket support into our Mibbit webserver.

The interesting part is this:

Currently, we use XHR long polling, keep alive. Basically a raw socket with
some HTTP header spam mixed in.

On the plus side, we can deflate/gzip the contents (unfortunately not across
messages, but still does well). But on the negative, the HTTP headers are
often about the same size or larger than the contents.

So, webSocket will improve the situation, in that there won't be HTTP header
spam. Also we'll be able to use a single connection instead of two (One for
sends, one for recvs). On the downside, there also won't be any deflate/gzip
(Unless implemented in js etc).

The other big bonus with WebSocket is you can connect to a different port.
Something that's not possible (For some idiotic reason) with XHR.

It'll be interesting to see which one wins :)

Pretty cool to see this in Chrome, I thought Firefox would be first to
implement it.

~~~
flashingpumpkin
_Pretty cool to see this in Chrome, I thought Firefox would be first to
implement it._

If you wade through the thread, you'll see that someone posted that
Firefox/Mozilla had it in trunk for nearly/over a year. Didn't check myself
though.

------
tlrobinson
Sometimes I'm glad I'm not famous enough to have everything I say scrutinized
and re-broadcast.

~~~
shawndrost
<http://twitter.com/shawndrost/status/6547879113>

------
jodrellblank
> Websockets let you use RHTTP. The client connects, sends a request to switch
> to RHTTP, then becomes an HTTP server.

This isn't going to be another SIP, is it? 'Yes we've all agreed on this
protocol, off you go and use it. NAT? What's NAT? Is it important?'

~~~
iamaleksey
Well, the NAT issue is almost solved with STUN
[<http://en.wikipedia.org/wiki/STUN>] and TURN
[<http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT>] (in those cases
where STUN is not enough). Together they make ICE
[[http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...](http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment)].

But none of these is needed for websockets to work.

~~~
crux_
N.b. --- those solutions only work for UDP traffic, not TCP; if you want to
use them and have a reliable stream protocol you'll end up reinventing TCP
atop UDP.

~~~
RiderOfGiraffes
"Reliable" and "stream" are different things. We often use (a variant of) RDP,
reliable datagrams. We often want packets with guaranteed delivery, but not
necessarily guaranteed order. We also use what we call USP (only partially
intentionally to confuse everyone) which is an unreliable stream protocol.
Packets aren't guaranteed to arrive, but if they do, they're in the right
order.

Such variants have their places.

~~~
crux_
True indeed (and that's why I used both words), although for a general-purpose
protocol intended for wide deployment, you probably want both properties.

------
cmelbye
Am I the only one not excited by WebSockets? It seems like a nice layer over a
new Comet method that's even more complex than the long-polling method that
we're using today. The server still needs to handle tons of open long-running
connections, but with WebSocket you have the added complexity of having to
support a brand new protocol in your web server - whatever that may be -
instead of one that your web server has supported since it was created.

Personally, I'd rather someone just write a minimal interface (i.e. not
Bayeux) to long-running Comet connections using XMLHTTPRequest. It should be
trivial after that to make it compatible with the nice API that WebSocket has
exposed.

~~~
jerf
"It seems like a nice layer over a new Comet method that's even more complex
than the long-polling method that we're using today."

Exactly backwards. Comet is a thick, ugly layer that is way more complex than
sockets. It adds staggering resource overhead to the real abstraction you
want; it will in the end be way _easier_ to support a ton of WebSockets than a
ton of Comet connections. (That may not be true of pre-optimized
implementations, but it will be true of final implementations.)

You don't add Socket support to your HTTP server... you have to add HTTP
support to your (TCP) Socket server!

This _is_ the minimal interface; it's Comet that's the hacked up hideous ugly
kludge that should never ever have been born because when that dude at
Microsoft went to add XMLHttpRequest, if he'd had a clue what that bastard
monstrosity would become, he would have created WebSockets right then instead.
I don't blame him, it would have taken a lot of vision at the time to
understand that. But _this_ is what we should have had from day one, and Comet
should never have been.

We have spent a truly astonishing amount of time in the web world deep in the
woods, failing to take advantage of simple things that have been known since
the 1960s. We've been in the woods so long that people have come to mistake
the hacks for the right answer. They're still hacks. Sockets are the not-a-
hack. (Though personally I'd still have gone for real sockets.)

~~~
cmelbye
I can write maybe 10 lines of jQuery and hook into some of EventMachine's
features using Thin as my web application server to use long-polling Comet. I
agree that it's not the best solution, but I don't think WebSockets does a
great job of fixing it. I also don't have a better idea though, so I suppose I
shouldn't be complaining ;-)

~~~
jerf
But that's not what you were complaining about. You said that sockets were an
additional layer over Comet. It's not. The fact that Comet is easy to use if
you slather on another couple of layers of code doesn't change that.

Furthermore, you will find, eventually, that WebSockets perform better, both
on the client and the server, and there is no amount of jQuery magic that can
change that, because the suckiness is fundamental to the nature of Comet.
Which again emphasizes the point that it is _Comet_ that is the layer of crap,
not web sockets. There's also a lot less that can go wrong since there's a lot
less code, and again, slathering on more code on top of Comet can't fix that.

~~~
cmelbye
My point is that long-running AJAX requests for Comet really isn't that
complex or ugly of a solution. I definitely agree that it's not the most
optimal (I believe it can sometimes cause problems once a large number of
requests have been made, right?) A solid, native browser implementation is
definitely the way to go going forward, but I'm saying that I'm not looking
forward to implementing a server for a new protocol that has the same server-
side problems as current Comet implementations.

------
InclinedPlane
If the AJ in AJAX uses web sockets instead of XMLHttpRequest, isn't it _still_
AJAX?

Besides which, the X in AJAX is JSON often enough nowadays.

~~~
jonny_noog
I guess it would be AJWS then. They're going to have to come up with a better
acronym than "Adj-wuss" before this thing takes off.

------
xanados
It will be great once web socket support becomes more pervasive. True 2-way
communication would be a great boon in the complexity department for a bunch
of different types of web apps.

~~~
ellyagg
Could I have a bittorent client running in Chrome?

~~~
daleharvey
they would need to provide a mechanism to allow connections to non origin
domains, like crossdomain.xml

I understand there are security implications, but I wish browser would stop
creating prohibitively strict restrictions on web applications and make a
somewhat sensible way too elevate permissions

(same origin model, access to the clipboard, etc etc)

~~~
mlinsey
In addition, the NAT issues discussed elsewhere in this thread would also be a
much bigger deal with P2P.

------
christofd
Something new to play with. Joe hits the sweet spot, regarding powerful &
pragmatic, again.

Websockets + Erlang... nice.

------
GeneralMaximus
Ah. So _this_ is why Google built their own browser. I fully expect to see
more goodies coming out of Mountain View in the future. Heck, even _I_ might
finally decide to play with web technologies :p

------
Jasber
As they discuss, will proxies have to specifically enable Web Sockets to allow
this to replace AJAX?

I thought this was the same problem Flash sockets had, traffic being blocked.

~~~
daleharvey
I think the biggest problem with flash sockets was the flash part :)

~~~
adatta02
the biggest problem with flash sockets is the insane security policy file
business.

