Slashdot Mirror
How Moore's Law Saved Us From the Gopher Web
Urchin writes "In the early 1990s, the World Wide Web was a power-hungry monster unpopular with network administrators, says Robert Topolski, chief technologist of the Open Technology Initiative. They preferred the sleek text-only Gopher protocol. Had they been able to use data filtering technology to prioritize gopher traffic Topolski thinks the World Wide Web might not have survived. But it took computers another decade or so to be powerful enough to give administrators that option, and by that time the Web was already enormously popular." My geek imagination is now all atwitter imagining an alternate gopher-driven universe.
I'm pressing ESC twice to access this damn BBS.
or try their hardest at least.
Even if the Web had been stunted by throttling, the demand for multimedia content would have eventually driven the rise of the Web or at least a super-Gopher.
Javascript + Nintendo DSi = DSiCade
Even if Gopher had dominated due to filtering (a premise I don't agree with), multimedia capabilities would have eventually been added to the protocol out of demand. We'd have the same web we have today.
Yes it was- people went nuts with images on their pages. I even remember one early commentator saying that text-only web pages were actually *better* for people on 14.4k baud modems.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Thats what is really stopping me from getting an iPhone, because I can't access badger-net.
People think that if Person X hadn't been around we might not have Technology Y. Okay, this is based on the idea that somehow Person X has some unique ability and only Person X can create Technology Y. Hate to break it to you, but you're not special. Neither is Person X. Second, the reason we have Technology Y is because we needed it. If those needs haven't gone away, then the pressure to fill that void remains -- and somebody else will come along and fill it eventually. Now you're right that maybe Betamax might have beaten VHS if not for a disturbance in the force, or it would have been HD-DVD instead of Bluray, or whatever... But we'd still have high density optical media. Gopher would have died simply because it didn't meet the needs of the population. Maybe it wouldn't be HTTP that replaced it five, or ten years later, but something like it would have been created.
#fuckbeta #iamslashdot #dicemustdie
'I even remember one early commentator saying that text-only web pages were actually *better* for people on 14.4k baud modems.'
As I recall (Get Off My Lawn, etc.) if you were on a slow connection the web pretty much became a text-only medium initially. I used Lynx rather a lot back then (for speed), while Mosaic tended to be a rather frustrating experience. One of the cool new features that got everyone excited about one of the early versions of Netscape was its ability to show you the text (and of course active clickable links to other pages) without having to wait for every single image on the page to load (assuming you had image loading turned on at all). Suddenly the web started to look like a useable medium rather than an over-ambitious experiment crippled by slow networks and unresponsive software.
Back in the mid-1990's, the most economical internet connection for small companies was a 64Kb ISDN link billed by the kilobyte, with a local university as the ISP. As most conference announcements were broadcast by USENET, the store-and-forward service was so slow, it was fairly common to have the conference, then receive the invitation three days later. If you wanted to download a file, ftp was likely to fail due to ISDN congestion that you would be forced to use a uuencode-by-email service. You E-mailed a message with the ftp path you wanted to download to the server, then it would download the file, chop it up and uuencode it back to you in lots of little pieces.
Otherwise, home users had the choice of a 14.4 kilobaud modem - some ISP's like Demon Internet built their own DOS window based application to manage E-mail/USENET postings. You could download the headers first, then pick out which full postings you wanted to download. Even then with a PC, you were still cramped for space with 40/80 Megabyte hard disk drives. One high resolution image from SGI could take up more disk space than you had on your PC.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Isn't there a reason, though? Presumably, using javascript/ajax, you don't need to send/receive as much information (i.e., reload the ENTIRE page) at a time. With plain HTML, you would have to receive a copy of the entire page again... ?
I see no reason why it should take less in normal HTML. Any explanations why you think so?
Perhaps, you worthless piece of crap, you should have my post. But being that you're too fucking stupid to probably even breathe without your genetically-diseased mother popping her head through the day shouting "Asswipe, inhale!", I guess I can forgive you your cretinism and illiteracy.
But please, quit trying to hump your dog. She's a he, and has been dead for a couple of years. I know, with your puny mind, it's hard to fathom necrophilic bestiality being wrong, but somewhere in the slack-jawed, low-browed head of yours there must be some small glimmer of morality.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The uudecode by email services were useful when my company had a UUCP connection via a nearby City Council (which was the only provider offering such a service to businesses at the time). We didn't have enough bandwidth for the binary newsgroups (9600 modem, IIRC), so that was the only way to get files without waiting for them to be shipped on CDROM so we could go to the one machine that had a CDROM reader and copy them off. ISDN wasn't available at our exchange so our first permanent connection was a 9600 leased line to the local University. At that point, direct ftp became a more attractive option than uudecode - which often took days due to throttling by the ftp-by-mail systems to control load, and we quickly learnt about the ftp reget and passive transfers to local servers to save international bandwidth costs (we were billed $4/MB for international traffic, but local traffic was free).
One of the things I downloaded was a graphical gopher program for OS/2. That was great - much better interface than FTP, even than the graphical FTP clients that had started to appear by then, it supported linking to images and binaries, but without support for ftp's reget, I didn't see the use for anything other than text. One of my co-workers showed me this great new program he'd downloaded for the FreeBSD box that was serving as our internet gateway - lynx. Comparing it to the graphical gopher, I found it unusable - links were scattered throughout the text instead of in a nice menu at the end like gopher, and predicted that this new http protocol would quietly die out along with other little known new protocols of the time. A few months later, someone downloaded a beta version of Mosaic. Now the web started to look worthwhile, and within weeks myself and co-worker who had introduced me to lynx came in on the weekend to replace the FreeBSD box with a new 486 running Slackware and a CERN webserver.
I founded one of the early online journals before the invention of HTML/HTTP. It's the Chicago Journal of Theoretical Computer Science, providing articles in copy-edited LaTeX source, as well as precompiled PS and PDF.
At first, the journal served papers through anonymous FTP.
Then, I crafted a Gopher structure to make browsing easier.
As soon as HTML/HTTP came along, I created the HTML version of the journal. It was much more maintainable than the Gopher version, because the hyperlinks decoupled the document structure from the file-system tree structure just enough. In a few years, I stopped maintaining the Gopher version, because it required an order of magnitude more work than the HTML, and readers all preferred the HTML anyway.
Adding pictures and stuff is rather trivial for the data architecture, although demanding for the network implementation. With a more maintainable structure, Gopher would have added the extras. It was the Hyperlinks that made HTML work better.
HTML also has some serious maintenance problems, but they appear later when the archive gets large, and they can be addressed with things like PHP compiling and content management systems.
From another point of view: Gopher essentially made file trees visible over the network (which is what I thought I wanted at first). HTML/HTTP provides a crude network database model distributed over the network.
Future advances in data architecture (as opposed to the types of data within that architecture) will have to do with other database models, and with other sorts of commitments between distributed servers, and with looser coupling between data ownership and server ownership. E.g., a way to provide reasonable assurance of future access to a particular data item (access includes being able to find it, not just its existence), without depending on a particular server at a particular registered domain name (the Wayback machine ameliorates the problem, but doesn't solve it).
Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
It's surprising that no one here on slashdot has pointed out that a major difference between the html and gopher was that gopher services had to get a licence from the University of Minnesota while http servers could be constructed without a licence.
Free open software with free open standards is what got the web going.