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.
