Gopher is awesome. It was my first real TCP/IP Internet experience in 1992. A high school friend and I discovered a terminal server at the local university that would allow telnet out w/o authenticating first. We would telnet to liberty.uc.wlu.edu, which ran public gopher WAIS clients that anyone could use. Having never seen anything like this before and not understanding hyperlinks, we assumed that navigating from one gopher server to another actually created connections between all of the servers. So, as we went from Texas to Virgina to California, Sweden, Japan, etc., we assumed that we were generating thousands of dollars in phone charges and that someone would eventually come looking for us.
There are certain modes where it simply cuts the connection when the server is done transmitting. There's no length header or end-of-transmission character or anything like that.
Once I did a little research and wrote it all out, Gopher actually came out worse than I thought. Even if it were brought up to Gopher+ specifications (which haven't been implemented by anyone in 20 years), it would still be way behind HTTP/1.1 in terms of fixing design flaws.
You are criticizing gopher from the point of view of "it must have the same features as HTTP". Some of the things you call "problems" are just different ways of doing it.
And if the TCP sliding window is an issue for you, why not fix TCP?
No, these are design flaws that anything over TCP/IP needs to deal with. In particular, closing the connection to indicate the end of a file transfer is really bad (what if somebody pulls an ethernet cord?)
Fix sliding window? I don't think you understand TCP. This is an optimization to TCP to prevent the need to ACK every packet. It means fewer bytes on the wire and less CPU load for TCP processing, while also maintaining a respectable degree of reliability.
TCP checksums are not sufficient for data streams of more than a few kB.
> Let's be honest, you just need to know how are you going to deal with the file, not what kind of file it is.
How you are going to deal with it is a function of what kind of file it is, so to know the former you need to know the latter. The internet Media Type system is far from perfect, but much better.
> You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image
If that was really all you needed, you wouldn't need the subtypes in the internet Media Type system, while experience in the real world has shown that you do need that information.
Because I want to differentiate between JPEG, GIF, and PNG images? The how is going to be different for each one. Without the protocol telling me, I can only make a reasonable guess on how to process it.
It's also my question - and the answer is a good one: Gopher provides one structured menu question answer like method to interface to information. This is why I use org-mode for most of my documentation.
The problem with using Gopher space is that most if not all information that I consume, hacker news, social media, wikipedia is available in gopher format. Some have implemented gopher versions of reddit and hn in the past, but these are gone.
In a way google serp, e-mail, twitter already use this simplified UI - now if only we could unify it somehow.
One way of doing this would be by using console browsers to interface the web, or set your browser to use 1 font and style and no images. One of these browsers, Elinks 0.12pre6 has gopher as compile time option as added benefit.
Aonther problem with Gopher is that it doesn't appear to support encryption and compression. I remember the pipe and slash symbols 'spinning' while waiting for a large plain text document to complete downloading in the old days. So the "resource lite" argument doesn't fly completely.
So perhaps the best option is to use simplified and structured gopher like menu-ing system using html, something like markdown did for html as is suggested... but why then not put Gopher to sleep for even and start a www-less project?
> I remember the pipe and slash symbols 'spinning' while waiting for a large plain text document to complete downloading in the old days. So the "resource lite" argument doesn't fly completely.
There really isn't a significant difference between the two. They both operate over a single TCP channel. HTTP/1.1 has a slightly higher header size, but it's not even half a kilobyte.
The only real difference is that HTTP usually serves up rich HTML, which contains all sorts of graphics and JavaScript toys and other bandwidth-hogging transmissions. If we limited HTTP to using HTML 3.2, no JavaScript, and only the occasional 2kb gif, it'd be resource lite, too.
FYI--I wrote the Apache::GopherHandler Perl module for running a Gopher server under Apache2, which I now consider to be mostly a waste of time. (https://metacpan.org/pod/Apache::GopherHandler)
Gopher's disadvantages compared to HTTP/0.9 were mostly legal/social rather than technical, IIRC, but that's very much not the case vs. HTTP/1.1. So there's probably an argument that, from a purely technical point of view, Gopher maybe shouldn't have been abandoned when it was, there's also no good reason to revive it.
I think it had some interesting ideas, but HTTP as it exists now is more flexible. On any given app, you'll run into Gopher's limitations long before doing the same for HTTP.
OK, then we'll just talk about it on its own merits:
* It closes the connection after every request, making poor use of TCP sliding window
* Binary file transfers are finished by the server closing the connection. There's no end-of-file marker or Length header.
* No provisions for caching
* A single ASCII letter identifies all file types
It's just a bad protocol design. HTTP/0.9 had many of the same problems, but that's not where HTTP is anymore. Gopher+ solves the single-letter identifier problem by using MIME types, but none of the other problems above. Not that anybody has ever implemented Gopher+, anyway.
Gopher+ does in fact resolve your second point by adding in a length header. All of your other points, with the exception of the TCP sliding window gripe, could be addressed through Gopher+ attribute fields. The Gopher+ specification [1] actually specified a "Mod-Date" field as part of the "+ADMIN" attribute, which could be used for caching. Even checksums could be added as well, through something like a "+SHA1" field.
Both the Overbite clients [2] and the Bucktooth server [3] support Gopher+. Pygopherd [4] also implements Gopher+. Many other clients support it as well; see a partial list in Floodgap's guide on using web browsers to access Gopherspace [5].
Gopher by itself is actually not hard to extend, as far as people standardize on how to extend it. That is why most of the discussions on "gopher enhancement" never resulted in big changes. Several ideas must be spread across the gopher project mailing list (now hosted at alioth, see archives at gmane), and some of them are quite good. The only consensus, though, seems to be that any extension is going to be done over plain gopher, not gopher+.
Why should we not compare it to HTTP? HTTP is the dominant current alternative for the role Gopher used to fill. If there is any merit to reviving Gopher, it can only exist in an advantage that Gopher has over HTTP.
As someone who formally got involved in the Gopher Revival, I was going to type up a big response to why Gopher sucks and should continue to be ignored. I decided to leave it for a blog post. See here:
I guess I shouldn't be surprised by this, but I am... my OS X Mavericks system not only has no built in gopher client, but there are zero results for "gopher" in the Mac App Store.
Yeah, it's kind of a bummer how rare Gopher clients are becoming. Since all the major browsers dropped Gopher support (and I think they all have, by now), it appears that ELinks[1] is the best Gopher client remaining, for *nix systems. And Android has Overbite. Not sure about iOS.
For Elinks gopher support one needs to compile from source with the gopher option (it's not on by default).
brew on osx doesn't download and compile the last 0.12 beta version (which includes gopher support). after: "brew upgrade elinks" it says: "elinks-0.11.7 already installed"
In the latest Ubuntu does install 0.12pre6 but it doesn't open gopher urls.
Elinks documentation says:
"It is still very experimental and the CSO phone-book protocol is not implemented. Default: disabled"
http://chals.sdf.org/gopher.cgi/phlog/2012/10-14-12/
Lynx works out of the box though, but I prefer elinks as it is the last (to my knowledge) updated console browser and it has features like ipv6, scripting and some javascript support.
One can always use OverbiteFF plugin or use the gopher proxies.
