Does it has functions for sending data, i.e. submitting forms? I'm curious if gopher could be a sufficient lightweight web protocol for all normal real life tasks including internet banking and shopping.
Gopher is extremely simplistic to implement because it basically can only do GET requests (but without all the header overhead).
All you need to do to retrieve a document is open a TCP connection and send the path you want to retrieve suffixed by CRLF. The server will then just return the requested data. For full text search (the only serverside expected feature for type 7 documents), add a tab character and then the search string.
The only other special feature on the client are Gopher menus which are a dedicated response type (type 1). They're basically the closest you get to rich text on Gopher - they're formatted text files which contain reference links to other addresses on Gopher.
It's all in all easy to see why Gopher got replaced. That said, I still recommend experimenting with it. It's very much a relic of a different time period, but that doesn't have to be a bad thing. HTTP and the general web stack has become rather bloated over the years due to its versatility. Gopher is laserfocused in its simplicity which gives it its own charm.
I say "I was building" rather than "built" because two things happened: someone showed me a graphical web browser that actually was usable, and whomever owned Gopher wanted to charge money for using v2 of the protocol (I think?). So I ditched all the gopher code I had written and made an HTTP-server instead.
update: I think it was Goper+, not Gopher v2 which was the new version
For sending data a Gopher server would need to be paired with an FTP server.
Imagine HTTP with only GET, no headers, no request bodies. RFC 1436 explicitly says:
> No state is retained by the server.
Reminds me that in 1996-7 we were also usually paying for items by mailing checks on eBay's AuctionWeb.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...