4 ms·
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 th
by chrissnell 13y ago
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 13y ago> Gopher is awesome No. Gopher is not awesome. It's a terrible protocol and it deserves to die.
- daemon13 13y agoThis is the first time I heard about Gopher. Why it's a terrible protocol?
- kalleboo 13y agoFor one, file types are represented by a single ASCII character http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_types http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_t...
- njsg 13y agoAnd 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
- frezik 13y agoBecause 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.
- dragonwriter 13y ago> 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.
- frezik 13y agoThere 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 13y agoI 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 13y agoYou 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 13y agoNo, 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.