top | item 6622602

(no title)

njsg | 12 years ago

Stop trying to compare it to HTTP, maybe?

discuss

order

frezik|12 years ago

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|12 years ago

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

dragonwriter|12 years ago

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.