In response to these two rebuttals to my HTTP rant, I’ll now add to my case…
First, I will use dumb arguments that hold little, if any, merit. These things are pretty obvious, but it’s good to just get them out for the record. Bear with me for a second:
- HTTP has been around since before 1990. It’s showing its age.
- Backwards compatability can be a good thing, to a point. But eventually you have to move on or start over.
- HTTP was designed for hypertext.
- It’s all about the messaging. If HTTP can do all this, why are we using SMTP also?
Perhaps a question that has to be asked is what’s the difference between SMTP and HTTP, then:
- It’s all just communication; messages.
- HTTP is an abstract way of messaging, through a different manner.
- SMTP is a more difened way of messaging.
- Different UIs.
User Interface / Protocol Relationships:
- Web Browser for HTTP
- E-Mail client for SMTP
- Chat client for XMPP
Another question that must be asked is if having defined UIs for Protocols is a good thing, as well as whether or not special UIs for convergence solutions are doing the right thing:
- Again, it’s all messages, just in different forms.
- It’s more than messages, even. It’s communication and information.
- The UI is the way, the Protocol is just the means.
Quoting from the first rebuttal:
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?
4? This works well for static data, and I intend on using inderection for data larger than about 2 MB, using BitTorrent and Gnutella networks However, dynamic metadata does not work well on distributed systems, and a client-server-server-client solution is better…
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?
- It’s not a pet protocol: Check out The Jabber Foundation and What is Jabber
- It’s client-server-server-client: me@pixelcort.com sends message to pixelcort.com, which sends message to yoursite.example.com, which sends message to you@yoursite.example.com. Yes, there are two middlemen, but it’s worth it. I maintain a constant connection to pixelcort.com from my client, you maintain a constant connection to yoursite.example.com from your client, and the two servers will maintain keep-alive connections as needed by messages being passed between them.
- Messages are XML. Create a schema, use a namespace, and you’re all set.
- You don’t know until you try.
I don’t care if everyone uses HTTP. I don’t care if it can be made to work. I don’t care if people can keep getting backwards compatability out of it. We can’t just use something forever. Why must we continue to tourture ourselves with it? Why can’t we play with new protocol-level things? Why must we maintain backwards compatability forever?
Sorry for the pseudo propaganda, but it’s time for a new era, a new renaissance, a nuWeb!
Pingback: Kinetic: Why I still hate HTTP