Overbite - Gopher Client For Android | Hacker News Reader

Overbite - Gopher Client For Android

gopher.floodgap.com

51 pointsmindcrime38 comments

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.

> Gopher is awesome

No. Gopher is not awesome. It's a terrible protocol and it deserves to die.

This is the first time I heard about Gopher.

Why it's a terrible protocol?

For one, file types are represented by a single ASCII character http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_t...

And you need more because...

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.

You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image

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.

> 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.

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.

I did a more complete writeup on Gopher's problems here:

http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/

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?

Why should the server send any kind of header?

Doesn't TCP do checksums, already?

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.

My first question, is gopher relevant? is answered here http://gopher.floodgap.com/overbite/relevance.html

Just for the fun of it, you should indeed read this using gopher,

gopher://gopher.floodgap.com:70/0/gopher/relevance.txt

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)

Overbite is amazing. They also have a gopher proxy and addons for Chrome and Firefox. Related:

http://gopher.floodgap.com/gopher/gw?gopher://gopher.floodga...

I'm fairly convinced that Gopher is technology that shouldn't really have been abandoned .. and maybe we'll see a return to such tools in the future?

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.

Stop trying to compare it to HTTP, maybe?

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].

[1] gopher://gopher.floodgap.com/0/gopher/tech/gopherplus.txt

[2] gopher://gopher.floodgap.com/1/overbite

[3] gopher://gopher.floodgap.com/1/buck

[4] gopher://gopher.quux.org/0/devel/gopher/pygopherd/About%20Pygopherd.txt

[5] gopher://gopher.floodgap.com/0/gopher/wbgopher

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.

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.

Weird thought of the day: a true, full REST interface seems remarkably similar to Gopher.

Now.. if HTML5 only included the ability to do AJAX gopher calls.

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:

http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/

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.

[1]: http://en.wikipedia.org/wiki/ELinks

Overbite has a list of plugins and clients that work on most platforms.

http://gopher.floodgap.com/overbite/

For iOS, there's GopherBrowse[0]

[0]http://itunes.apple.com/us/app/gopherbrowse/id478840815

For iOS there is the free gopherbrowse "A small pittance is requested to defray the Apple developer tax". https://itunes.apple.com/us/app/gopherbrowse/id478840815

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.

GopherBrowse is actually free in the AppStore. No pittance required, small or otherwise.

Older, gopher-specific clients, can be interesting, too. Some day I should try to get gopherVR running on my machines.

You could always resort to browsing using telnet or netcat, or write your own client in a few lines of your favorite language.

True, but just using elinks works well enough for me.

would you pay for gopher client? if yes - how much?

... Compile one?

http://gopher.quux.org:70/give-me-gopher/

Reply on news.ycombinator.com