Slashdot Mirror
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?"
Let's all just capitulate and make the official format a Microsoft Word document.
Michael.
Linux : Mac
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?
I watched C-beams glitter in the dark near the Tannhauser gate.
Given that all the technologies you mention work just fine across the internet as we know it....
Why think about getting rid of html/http?
The pure simplicity of developing and publishing content is what made the WWW take off the way that it did. Anyone could (and generally did!) build a site. It was an information revolution.
The other technologies will handle the more demanding apps out there. But HTML/HTTP is why the web (and in a larger sense) the internet is what it is today.
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.
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.
(Spudley Strikes Again!)
That topic should've been changed to 'PDF To Yo Momma'
Sorry, my bad.
Why is it that developers feel the need to periodically scrap everything they've been working on, then reimplement it, usually in a more half-assed way than the original? (I'm talking to you, Apache programmers! ;)
But seriously, where's the need to dump HTTP? It's not exactly a complicated protocol, and can be adapted to do many different things. Pretty much any protocol can be tunneled over HTTP, even those you'd normally consider to be connection-orientated socket protocols.
As for HTML, again - why the need? By using object tags and plug-ins, the browser is almost infinitely extensible. Flash and Java bring more interactive content, streaming brings sound and video, PDF brings exact display of a document to any platform, and people are using all sorts of different XML-type markups every day now, such as RSS, XML-RPC, SOAP, and so on to do all kinds of interesting things like Web Services and RPC.
Microsoft and the open source community are both working on markup-like things that will enable applications to operate over the web (all via HTTP). XAML and XUL's descendents might well have a big future, especially if the way documents should be displayed is more rigourously specified than HTML.
The fact that HTTP is stateless is one of the reasons that Apache and the kin scale so effectively. The instant they're done dealing with the request, they cna do something else without thinking about the consquences. Why do I need state on my personal homesite? I don't. Let your application logic deal with state. Let the protocol deal with data transmission period.
Please study TCP/IP better before you ask such a question again.
You are being MICROattacked, from various angles, in a SOFT manner.
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. =)
Forget ditching HTTP, it's good even with its quirks. It's easy to use... And it's near perfect for applications designed with the REST philosophy in mind.
Instead of ditching HTTP, let's ditch SOAP-RPC.
You gloss over, with a sweep of your clueless wand, the rest of us who rely on the Internet for things like SMTP, SSH, Muds, Usenet, IM and VPNs.
Please don't assume that my Internet is the same as your Intarweb.
I want to delete my account but Slashdot doesn't allow it.
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.
Canvas? Try SVG, in a SVG aware browser. Not javascript accessible, rather ECMAscript accessible.
Let's see:
* The primary addressing mechansim would be content-based addressing (like SHA1 hashes of the content being addressed). We have problems with giving reliable references for things like bibliographies. We are gradually moving in this direction. P2P networks are now largely content-addressed, and bitzi.com provides one of the early centralized databases for content-based addressing.
* We would have a global trust mechanism, where people can evaluate things and based on how well other people trust their evaluations, those people can take advantage of their evaluations. Right now, web sites have very minimal trust mechanisms (lifetime of domain, short domain names, and the generally-ignored x.509 certs). This would apply not just to domains, but be more finely-grained and apply to content beneath it.
* The concept of creatable personas would exist. Possibly data privacy laws would end up requiring companies not to associate personas, or perhaps we would just make it extremely difficult to associate such personas. You would maintain different personas which may, if so desired, be separate. Such personas would be persistent, and could be used to evaluate how trustworthy people are -- e.g. if Mr. Torvalds joins a coding forum and makes some comments about OS design, he can simply and securely export his persona (a pubkey and some other data) from the other locations that he has been using that persona (like LKML, etc) and benefit from the reputation that has accrued to that persona. This would eliminate impersonation "this is the *real* Linus Torvalds website", etc.
* Such trustable, persistent personas would allow for the creation of systems to allow persistent contact information to be provided ('snot that hard). This means no more dead "email addresses".
* Domain names not be used as the primary interface mechanism to users for finding and identifying data providers. This is halfway handled already -- most people Google for things like "black sabbath" instead of looking for the official Black Sabbath website by typing out a single term. It's still possible for people to "choose their visual appearance", though, and Visa looks very much like "visa-checking.com", as long as end users have control over how domains are presented to users.
* P2P becomes a primary transport mechanism for data -- from an economic standpoint, this means that consumers of data are responsible for subsidizing continued distribution of that content, and shifts the burden from the publisher of the content -- one step removed from consumers funding the production of their content. It solves many of the economic issues associated with data distribution. For this to happen, P2P protocols will have to be strongly abuse-resistant, even if that means a lesser degree of performance or efficiency. Many existing systems have severe flaws -- Kazaa, for instance, allows corrupted data to be spread to users, and conventional eDonkey (sans eMule extensions) does not provide any mechanism to avoid leeching, which destroys the economic benefits. Sadly, one of the few serious attempts to address the stability of the system was also from Bram Cohen of BitTorrent and abandoned -- called Mojo Nation, it used a free-market economic system to determine resource allocation, and was fairly abuse resistent. I have some efforts in this direction, but don't use a free-market model.
* Email and instant messaging will merge to a good degree (or perhaps one will largely "take over"). Up until now, it has mostly been techncial limitations in existing software that has kept one from supplanting the others -- email provides poor delivery-time guarantees, instant messaging provides message size limitations. Email uses a strictly thread-based model, instant messaging uses a strictly linear model. Probably someone will coin a new, stupid term for the mix of the twain (like "instant mail").
* Personas and global trust networks (not extremely limiting binary-style trust, a la PGP/GPG), as mention
May we never see th
I really hate Flash.
I hate Flash for a lot of reasons.
*) Lots of web designers think animation is a good idea. They tend to use it more than a user would like (especially since the "is it cool" metric, where users are asked for initial impressions of a site rather than to use the thing for a month and their feelings on usability) is wildly tilted toward novelty. Animation is almost never a good idea from a usability standpoint on a website.
*) Lots of people doing Flash try to do lots of interface design, going so far as to bypass existing, well-tested and mature interface work with their own pseudo-widgets. They usually don't know what they're doing.
*) Flash is slow to render.
*) Flash is complex, and it's hard to secure the client-side Flash implementation compared to, say, a client-side HTML rendering engine.
*) The existing Flash implementation chews up as much CPU time as it can get.
*) Flash does not allow user-resizeablity of font sizes.
*) Flash does not allow for meta-level control over some things, like "music playing in the background". Some websites provide a button for this. I don't want to have control if the designer choose to give me control -- I never want that software playing music if I choose to not have it do so.
*) Flash does not allow user-configurable font colors (and for some reason, too many Flash designers seem to think that "ten-pixel high light blue text on dark blue looks great to them, so everyone should also be able to read their site as easily).
*) Because Flash maintains internal state that is not exposed via URL, it's not possible to link to a particular state of a Flash program -- this means that you can only link to a Flash program, not a particular section of one. This is very annoying -- I can link to any webpage on a site, but sites that are simply one Flash program disallow deep linking. (I'm sure that concept gets a number of designers up somewhere near orgasm, but it drives users bananas.)
*) The existing Flash implementation is not nearly as stable as the other code in my web browser, and takes down the web browser when it goes down.
*) As you pointed out, I can't search for a "page" in a Flash program.
Really, the main benefit of avoiding Flash to me is that it keeps web designers from doing a lot of things that seem appealing to them but are actually Really Bad Ideas from a user standpoint. Almost without exception, Flash has made sites I've used worse (the only positive example I can think of was either a Javascript or Flash in which the manufacturer of a hardware MP3 player demoed their interface to website users).
I *have* seen Flash used effectively as a "vector data movie format", for which it is an admirable format -- I suspect most Slashdotters have seen the Strong Bad cartoons at some point or another. But I simply do not like it as an HTML replacement.
May we never see th
You know exactly what he meant, and simply couldn't pass up the opportunity to bash him to demonstrate your maximum geekiness.
Please study TCP/IP better before you ask such a question again.
You know what I've found? Professors and people that generally understand a subject are generally not assholes towards people that make an error in it (maybe if they're frusterated) -- they try to correct errors. It's the kind of people that just got their MSCE who feel the need to demonstrate how badass they are by insulting others.
The question was not unreasonably formatted. The most-frequently used application-level protocol on the Internet is HTTP. The only other protocol directly used much by almost all Internet users are the mail-related protocols. The main way that people retrieve data and interact with servers on the 'Net is HTTP. Often, the HTTP-associated well-known ports 80 and 443 are the only non-firewalled outbound ports allowed to Internet-connected desktop machines. You're using a Web browser to read this at the moment. Other protocols are increasingly tunneled over HTTP. Saying that we have an "HTTP Internet" is entirely reasonable.
May we never see th
If all those things in the title were used to develop a website, i think the things one could accomplish are amazing. as it stands you can already use xhtml and xhmlhttprequest to do highly dynamic websites.
"highly dynamic websites". Hmm. What specifically do you mean by this?
i wish browsers could automatically detect what version of html the webpage requires, and generate warnings if your browser's too old to properly render, with a handy "update here" link.
Browsers and website designers already have the ability to do this. The reason they don't is that it's a pain in the ass for the user.
May we never see th
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!
-Billco, Fnarg.com