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.
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
...would be to finally switch to IPv6; that would solve a lot more problems than mucking about with HTTP. Oh yeah, that and banninating IE from the Computosphere.
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.
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. sometimes i wish so much emphasis wasn't put on backwards compatability in the web. 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.
PS: Canvas is a new tag from apple, used to draw things into an img like component. apple's working with opera and mozilla to integrate it into their browsers. hopefully this will go somewhere. i've always wanted something like that directly javascript accessable, but have never had the luck. it requires hack extensions like java and flash which don't communicate well with the underlying javascript without using some kludge like liveconnect.
- tristan
I heard a bunch of stuff about XTP a while ago, but not much recently.
Here's what Google finds:
http://www2.ics.hawaii.edu/~blanca/nets/xtp.html
http://www.cs.columbia.edu/~hgs/internet/xtp.html
A speech...
smart caching (P2P)
"P2P" isn't smart caching. And many common implementations actually use HTTP.
rich metadata (XML)
XML is an easy to parse syntax for hierarchical data. It has nothing to do with "rich metadata".
Any ideas on how you would develop a post-HTTP/HTML internet?"
Sure. I'd refactor XHTML to include more useful element types (e.g. <navigation>). I'd switch protocols like SMTP and formats like RFC2822 over to Unicode/XML. I'd make maintaining state something intrinsic to HTTP. But first of all, I'd beat people who use buzzwords without understanding what they mean with one gigantic, fuck-off-big cluestick.
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.
I blame the /. editors for allowing such a stupid question to be posted.
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.
Success is as dangerous as failure, hope as hollow as fear.
Thos of us who have been using the "internet" for a LONG time realize this. Everything changes.
Gopher use to be the most popular way to get information on the internet, that has been replaced by HTTP. Who uses gopher anymore? It's still out there, it's still usable.
Look at the history, the internet was started to exchange data with colleges. Ok great, email was pretty much it's first major use, then along came FTP, and then along came gopher, then along came HTTP.
HTTP will never be replaced or "go away" something new may come out to be used the most.
Personally I want a protocal to replace IP. I want verified connection lists, basically a firewall built into the protocal, to only allow verified connections and warn on others.
I want IP privacy masking, meaning If I connect to a server, it won't record my IP, and my IP will never be seen on the public network. The phone company can "block caller ID" Why can't an ISP block "host IP?"
The list could go on and on
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.
So instead of trying to prove that you're smarter than the average \.er by playing with semantics, how 'bout putting that noggin to better use and answering the question. Clearly you are an expert on the field in question and must have some good ideas.
My suggestion? Think of a browser-website connection as analagous to a client-server database development. Where is the latency? It's in establishing connections. What if HTTP had connection pooling? Seems like it would speed things up significantly.
May no camel spit in your yogurt soup.
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.
Do you remember the Net prior to HTTP and the web? if so you can easily see why "the web" took off like it did.
You need to develop a new protocol/app that provides something people actually want without added complexity and you'll replace the web as quickly as the web replaced usenet/gopher/ftp/irc (I know it didn't replace all of those things but for the majority of uses and people it did to some degree render them obsolete)
Of course if your new system was really a wanted thing and was open enough to become a world wide standard someone would probably just patch it into a browser in someway as to make it accessible from current websites the way flash is accessable from HTML, and then not only would people call your thing "the web" anyway they would only be using the bare minimum to get the new *feature* they wanted.
The Web took off because it worked. You couldn't really patch images and hyperlinks onto FTP the way you can seemlessly access email/usenet/(*insert here*) over HTTP with the proper server. just wouldn't work.
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
Personally I want a protocal to replace IP. I want verified connection lists, basically a firewall built into the protocal, to only allow verified connections and warn on others.
IPSec? At the application level, SSL?
I want IP privacy masking, meaning If I connect to a server, it won't record my IP, and my IP will never be seen on the public network. The phone company can "block caller ID" Why can't an ISP block "host IP?"
Oh, it can. Lots of ISPs provide web proxies, in particular (they'd probably be tickled pink if people would regularly use proxies, and save them bandwidth costs). However, it makes it even easier for the ISP to track you. The majority of people I've talked to interested in masking are primarily interested in not having illegal activities tracked, and if anything, it's easier for police to find out an identity by going to the ISP and asking for their logs.
There's already been a full anonymity service provided by Zero Knowledge Systems. They even provided onion-skin routing within their own network to make external traffic analysis on their network a pain in the ass. Nobody bought it -- people don't understand or want to pay for anonymity. ZKS went on to do other things.
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
I see no fundamental barrier to something like this.
No, but it is easier for a chip engineer to make optimizations with constant-length addresses.
And, honestly, as long as we're using IPv6 addresses as actual addresses, as they're intended to be used, I just cannot see length being an issue again. (Problems will come up if some idiot tries ramming additional data into the thing, like a MAC address.)
May we never see th
Yeah, you're basically an idiot.
First, I would re-design IP to take variable-length addresses, so IPv4, IPv6 and everything else to come are all compatible and interchangable.
... I guess you'd make every protocol SSL-tunneled? I mean, I think it's a good idea (more plaintext services becoming encrypted == better), but you can already do that, and the main reason that people don't is because of (now archaic) patent issues and because of CPU load. Also, SSL adds overhead, not just on the CPU, but in latency.
As I go into detail in in my post futher in this thread, I don't think that this is a good idea. It makes optimizations harder, and IPv6 should never need to be extended as long as it is properly used. Furthermore, unless a new protocol uses the *exact same* routing mechanisms and *only* changes address length, compatibility gets broken anyway. I think the gain may not be what you're hoping for -- you couldn't just slap IPX on an IP network, for example.
I do think that the fact that the BSD sockets API was designed to deal so poorly with long addresses is a real disaster, though. The *endpoints* of a connection-oriented address generally only care about the length of the address.
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.
SMTP/HTTP are not resource types. They are protocols.
You could have a "WWW" resource type, I guess.
This is already done, with well-known ports -- the advantage of using well-known ports is that the additional network traffic and latency is avoided.
I would unify all the protocols under a single HTTP-like protocol and make everything, FTP, SMTP, NNTP, etc. a direct extension of it.
Hmm. I dunno. I guess you could wrap these in HTTP, but where's the benefit of doing so? You can't really reuse any significant functionality and you'd slightly increase complexity (since everything would need to be linked to an HTTP library).
I would merge CGI and SMTP DATA into a single "data" mechanism that could be used with any of the protocols uniformly.
Hmm. I'm not quite sure what the benefit to doing so would be.
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.
Wouldn't this just impose overhead on protocols that use an eight-bit-clean and non-line-oriented interface, like FTP DATA?
I would also move SSL authentication into that protocol, rather than having it at the TCP level.
Not sure what you mean
This would make shared hosting simpler and would save us a LOT of IPv4 numbers.
I don't see why this would be the case.
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.
Thank you. I've seen one utterly idiotic proposal for doing something like what you're proposing and ramming everything through XML, which is ridiculous.
XML may be the most overused and oversold format ever. It's neat for a certain set of tasks, but it has no benefit for many things that it is used for.
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
"P2P" isn't smart caching.
Almost all existing P2P filesharing-oriented servents reshare downloaded files. From that standpoint, the statement is not unreasonable.
And many common implementations actually use HTTP.
Not that I'm aware of. Gnutella uses an HTTP-like protocol, which is as close as I can think of.
Sure. I'd refactor XHTML to include more useful element types (e.g. ).
I disagree. The current behavior of navigation controls operates on a meta-level -- the operator never gets control over what they do. In the past, giving website designers over control of web browser controls has widely resulted in poor decisions being made -- IE has taken a "web designer has control" approach, Mozilla a "user has control". Plus, it only takes a small percentage of poor usage or abuse of controls ("back" keeping people on the same ad, for instance) to make a control not worth it.
I could see a *new* set of interface controls "recommended-back", "recommended-forward", "recommended-up", "recommended-help", etc being introduced, but not overloading the existing controls.
I'd switch protocols like SMTP and formats like RFC2822 over to Unicode/XML.
Why do you dislike the existing MIME-encoded method of handling Unicode data?
What would be the benefit of XML usage?
I'd make maintaining state something intrinsic to HTTP.
Why? Demands for state maintenance vary widely across HTTP-using systems -- web browsers can be pigeonholed, sure, but cookies are already there and work nicely. What if you need five megs of state (different mechanism from cookies), or need to have the client aware of the content of the state? There are a lot of systems that can't afford to maintain state, like embedded systems.
But first of all, I'd beat people who use buzzwords without understanding what they mean with one gigantic, fuck-off-big cluestick.
I really don't think that he was all that awful, really.
May we never see th
Use of such a mechanism is not compliant with the Americans with Disabilities Act. The proper, legal approach is to embed WAVE files of the text being read, and verbal descriptions of all graphics.
Furthermore, citation is a significant problem on the Internet (for example, used resources can go away if cited by URLs). We need to solve the citation problem -- the appropriate approach is to embed all files used as sources of content for the existing file (which would, in turn, contain copies of all *their* sources, etc).
May we never see th
That is correct. In spite of the similar names, they have almost nothing to do with each other, beyond the fact that html is often delivered via http.
What you are saying is not contrary to what the article author said in the first place.
May we never see th
All documents should be XML (or some other data discription language.) CSS's sucessor should be used to assign elements presentation. Possibly by converting them to other element trees.
The XML should be psuedo-standardized, so browsers would be able to recognize TV-Listing-ML/Search-Result-ML and present it in an alternate form, if you wanted, with headers and footers added (to make advertisers happy, unfortonately necessary for a new Web protocol to suceed.)
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
It's been tried but it requires Windows 2000 Professional or better, Microsoft Internet Explorer 6, IIS 6, and SQL Server 2000 or better. Version 2 requires Microsoft Longhorn.
I think the nicest thing I can say about XML is that sometimes it isn't blatantly inferior to any other solution. Sometimes.
Tim
Omnia vestra castrorum habetur nobis.
I don't really see a need to wholly move away from HTTP and HTML. They're both extremely flexible and will likely be very useful for many years to come. They're both relatively basic systems that aren't terribly difficult to implement with a modicum of programming talent. They're also extremely lightweight which makes it much easier to use them on equipment with very little power of memory.
Because HTML is fairly verbose and well formed HTML is regularly laid out it isn't terribly difficult to parse. Computers with a fraction of the processing power and memory available to modern PCs can easily handle HTML files. Well formed HTML and especially XHTML documents are actually very useful because they can not only be easily parse but also easily handled by a variety of output devices. What is doubly useful about HTML is it can also point in an implementation neutral means to other documents. This is what hypertext is all about, text that can describe itself to anyone who is listening.
HTTP as a protocol is extremely useful because it is stateless and as such has very low overhead. Because of this it is very easy to implement and maintain. These features also make the protocol very robust and extensible. It can handle binary and textual data equally well and even tunnel other types of protocols inside of itself. These features that don't need to be replaced or necessarily enhanced.
I'm a loner Dottie, a Rebel.
I think the future of the internet will be using technology such as the BitTorrent idea, to take advantage of the high client to server ratio to distribute content more effectively. This would truly make the web (the World Wide Web that is) interconnected.
Doesn't sound like much, but the biggest improvement over HTTP is merely a persistent connection.
My ideal vision of the future of the internet is basically a version of Apache that supports persistent connections, so I can go back to the days of BBS, only with graphics and streaming video added. Or would we call them MMOBBSes now?
People accept the limitations of html and http because its currently the best thing out there. It does have problems, though:
Scalability. A server that isn't well provisioned can easily be slashdotted or DDOSed into oblivion. Not everyone can afford a DS3 or akamai. This problem could be solved through replication.
Document identity. A document's location is a permanent part of its file name. If a document moves, its contents are the same, yet its name changes. Sometimes, its nice to be able to retrieve a document knowing only its name, hash or, md5sum. This how many distributed hash table-based p2p systems, like chord, tapestry, freenet, and CAN work.
Lack of Backlinks. There's no way to ask "what points to this page?" without crawling the whole web. (I know google allows backlink querries, but they're not necessarily up to date.)
Lack of meaning in links. I would like to be able to associate adjectives and weights with my links, as a hint to search engines. As in "a href=http://slashdot.org relevance=1.0, accuracy=-0.5, novelty=0.8". I think this sort of thing is supposed to be addressed by the semantic web.
-jim
For a web applications solution [HTTP is a great protocol that should't go anywhere!], I'd propose a new protocol much like IBM's 3730 or 5250 terminal sessions... as a starting point. The idea is that the machines should negotiate a connection and then maintain it's integrity while the app is running. Nowdays, most people have reliable enough connections to support this and having a persistant client-server connection would solve many of the programming issues involved. I'd add a laundry list of new features starting with the ability to peer-to-peer browsers, co-browsing, as well as all the latest security implentations. The main difference is that the machines have to have some element of trust between them...you would be cedeing control of your "browser" to whatever server you were on ...that would require heavy-duty java-style sandboxing of your system and between systems you might be linked to.
The only way to get a good version would be to start as OSS...otherwise it would be immediately hijacked in any "committee". Like I said, a starting point would be the old terminal sessions..perhaps bring them up-to-date by allowing the stream to include XHTML markup and a DOM instead of strict screen coordinates! Ideally, it'd be "just a plugin" for mozilla or firefox. One key point I would try to make is to make it as radically different from HTTP/HTML we have now as possible! because it would start out OSS It should be "hobbled" in some respect to force people not to use it for general browsing purposes. That way we could start to push multi-protocol sites rather than just shoving everything into HTTP or it's successor.