Features of a post-HTTP Internet?

Ars-Fartsica asks: "We've been living with HTTP/HTML ("the web") for a quite a while now, long enough to understand its limits for content distribution, data indexing, and link integrity. Automatic indexing, stateful-ness, whole-network views (flyovers), smart caching (P2P), rich metadata (XML), built in encryption, etc are all fresh new directions that could yield incredible experiences. Any ideas on how you would develop a post-HTTP/HTML internet?"

Wrong question.

[daeley]

Any ideas on how you would develop a post-HTTP/HTML internet?

First identify the problem, then you can start devising solutions.

So what's the problem? You mention certain limits of HTTP/HTML. Would these be overcome with better applications rather than throwing everything out?

Why does HTTP have to go away?

[dougmc]

So, HTTP (and HTML, though the two really have nothing to do with each other, beyond the fact that HTTP is the primary way of delivering HTML) can't do everything. We know this. We have always known this, for as long as we've had HTTP.

Has something changed that I'm not aware of here?

HTTP may be the most popular protocol out there, but it's hardly the only one. SMTP is really popular, FTP, NNTP, IRC, whatever all the IM systems use, UDP protocols used by games, DNS ... many of these may be showing their age, but they're not showing any signs of going away any time soon.

LaTeX

[Anonymous Coward]

I've been saying for years that if we had only adopted LaTeX as the primary means of displaying Web documents, we'd have a considerably more wonderful content delivery system.

(LaTeX, being a programming language, is quite adept at laying things out, and accepting new sorts of extensions. It would be ideal for this kind of display ...)

Forget HTTP.

[Spudley]

Forget about replacing HTTP - let's deal with the real problem protocol first: SMTP.

Please! Someone give us a secure email protocol that doesn't allow address spoofing.

Unification

[Cranx]

First, I would re-design IP to take variable-length addresses, so IPv4, IPv6 and everything else to come are all compatible and interchangable.

Then I would re-design DNS so that you have to provide not just a domain name to resolve to an IP number, but a "resource type" such as SMTP, HTTP, etc. (similar to MX records, but generic). Each resource type would have its own associated IP number and port.

I would unify all the protocols under a single HTTP-like protocol and make everything, FTP, SMTP, NNTP, etc. a direct extension of it.

I would merge CGI and SMTP DATA into a single "data" mechanism that could be used with any of the protocols uniformly.

I would clean up the protocol so it's possible to concatenate multiple lines together without ambiguity, and uniformly, so the method for multiple line headers is the same as multiple lines of data.

I would also move SSL authentication into that protocol, rather than having it at the TCP level. This would make shared hosting simpler and would save us a LOT of IPv4 numbers.

I would peel the skin off of anyone who suggests that XML become an integral part of that protocol. XML is wordy, wasteful, hard to read and should be a high-level choice, not a low-level foundation.

That's not all I can think of, but that's all I'm going to bother with right now. =)

Flash

[beholder77]

Macromedia did a great presentation to my org on the idea of turning websites into live applications with flash. As a web developer I found the whole idea to be quite cool. Flash seems to give a heck of a lot more flexiblity and control than any HTML/Javascript hackery I've seen. The apps I saw demo'ed were even communicating with a DB server using web services.

Flash has it's drawbacks of course (proprietary and non-indexable being pretty critical), but if opened up to a standards body, it could very well be the next HTML.

There is no problem with SMTP

[Anonymous Coward]

If you think there's a problem with SMTP, then you don't understand what it's doing.

Claiming that there's a 'spoofing' problem with SMTP is like saying there's a 'spoofing' problem with HTTP, because *anyone* can put up a website claiming to be anyone else.

It's *NOT* a problem with the delivery protocol.

There already is a way of preventing address spoofing with email - it's called PGP, and using it doesn't require any change of SMTP.

Re:XML + XForms + XMLHttpRequest + canvas

[NoMoreNicksLeft]

Canvas? Try SVG, in a SVG aware browser. Not javascript accessible, rather ECMAscript accessible.

Re:Wrong question.

[aklix]

HTTP is a transfer protocal that does everything I need it to do. As for HTML, we practically have a post-HTML internet. DHTML, Javascript, CSS, pretty soon Apple's Canvas. It all works nice and pretty. So why would we need a post HTTP, especially if we have other protocals to do other things.

HTTP is fine

[billcopc]

HTTP is fine, a stream-transfer protocol can only do so much.

HTML however feels rather clunky now with all these bloated half-supported standards tacked onto it. We still don't have consistent rendering across the board, and it's still a pain in the posterior to publish anything. CSS, that wretched hammer of aborted salvation, is yet another limited hack.

We used to have HTML glitches and workarounds, now we have CSS glitches and workarounds; design compromises in a system that was supposed to break the boundaries of visual layout. Well here we are 5 years later and the graphics artists are still using Flash instead of CSS... I even collapsed and learned the dark art of PHP-generated Flash to do some things that just weren't worth the trouble in CSS. Content is king, but we have 256mb video cards and we want to use them!