Most people agree that SMTP sucks, and that it’s time to move on. However, almost everyone whom I’ve spoken with seems to still have an affection to HTTP, for one reason or another.
As said nicely in If you must poll, at least poll well, in the end, HTTP just won’t work. Yes, we can do RFC3229 – Delta Encoding, but that still doesn’t solve the polling problem. 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.
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?
Yeah, the other part of the project is the use of Magnet-URIs to refer to multimedia objects, in a way that the user sees the downloaded media inline with the message. It’s like using the src attribute in XHTML, just having the browser not download the media to a file on the desktop; rather it caches it and displays it as if it had been done through HTTP. In this case, the cache is also used by the local P2P client as a sharepoint. This is all just for the sake of saving bandwidth where it can be saved.
In the end, HTTP is too many’s saviour, since it offers developers with a place of ultamite control with little fuss. I think that the same can be done in XMPP, provided good clients.
Why? To save people bandwidth; from Microsoft to that indie movie producer. To make things faster, from being able to get new metadata the instant it’s published, to being able to download media without fear of burdening the author’s own bandwidth. I hate HTTP. That’s my inspiration behind Project nuWeb.
Pingback: Mod-pubsub blog