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