
Overbite - Gopher Client For Android - mindcrime
http://gopher.floodgap.com/overbite/d?android
======
chrissnell
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.

~~~
the_mitsuhiko
> Gopher is awesome

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

~~~
daemon13
This is the first time I heard about Gopher.

Why it's a terrible protocol?

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

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

[http://www.wumpus-cave.net/2013/10/27/why-gopher-is-
awful/](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.

~~~
njsg
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?

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

------
eitland
My first question, is gopher relevant? is answered here
[http://gopher.floodgap.com/overbite/relevance.html](http://gopher.floodgap.com/overbite/relevance.html)

~~~
fsiefken
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?

~~~
frezik
> 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](https://metacpan.org/pod/Apache::GopherHandler))

------
a1a
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...](http://gopher.floodgap.com/gopher/gw?gopher://gopher.floodgap.com:70/0/gopher/relevance.txt)

------
fit2rule
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?

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

~~~
njsg
Stop trying to compare it to HTTP, maybe?

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

~~~
mintplant
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

~~~
njsg
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+.

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

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

------
frezik
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/](http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/)

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

~~~
mindcrime
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](http://en.wikipedia.org/wiki/ELinks)

~~~
fsiefken
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](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/](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.

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

