"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.)
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 ;-)
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.
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.
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.)