Even if a million people check using all of these bandwidth savers, that’s still a million TCP connections being opened and closed. That’s just not going to scale well as we get larger and larger audiences.
This sounds like a simple interview question at Amazon - "so, how would you make it work anyway?". Okay folks, let's break some assumptions: Not every client has to connect to the One True Server. There is this concept of an 'intermediary'. You can use this to place a thousand caching servers that retrieve the data, then clients retrieve from those servers instead. One level of indirection gives you n*2 more scalability. Two levels give you how much? Anyone? Anyone?
HTTP servers can only speak when spoken to. They can’t just connect to the client, the client has to initiate the connection. Even with keep-alive, they still have to wait until an HTTP method is incurred. By not being able to have that two-way communication, how can we truly maintain HTTP as our protocol of choice?
Well, duh. Of course. And this is a unique problem because... what? The solution is simple and applies to any protocol - put a server on the desktop & send it a message. And for your next complaint in this sequence, here's a question for you - how is your pet protocol going to post messages to a desktop without the client opening a socket (like an http server) or initiating a connection (like an http client) of some kind?
See http://www.mod-pubsub.org/ for an example of a client that initiates a connection and then consumes a stream of event notifications on that connection. There are clients in multiple languages (Java, Perl, Python, C++) and even two servers (Perl, Python). The neat thing is, it's just HTTP, so all the documents & design has been done. You just have to follow in someone else's footsteps.