------------------------------------------------------------
       Technology/Gopher, (sdf.org), 12/12/2018
------------------------------------------------------------
Ok gopher folks, I want to pick your brains. I'd like to
know how "pick your brains" translates in your native
languages, but that's not the point of this post. The point
is to attempt as full a sketch as possible of the actual
differences and similarities between the HTTP and GOPHER
protocols.

A discussion on another system is prompting this
investigation. I won't quote directly, because the other
party didn't give me permission to do so, but I'll
paraphrase what they said: 1) that gopher is out-dated and
should be allowed to die; and, 2) that HTTP can do
everything that Gopher can do, and do it better. That's
at least my memory of my interpretation of what they said,
actual facts and events are not available presently.

I told them that I'd ask gopher, an obviously biased
audience. They didn't say not to (of course, they were
leaving on a trip and haven't had time to respond... but I'm
sure they won't mind.)

So, here I am. I'll start by providing what I believe are
accurate bits of technical information, both in how the two
protocols resemble one another, and how they differ. I am
assuming that you folks will help augment this and correct
any errors:

From what I gather, these are the similaries:

1. Both gopher and http start with a TCP connection on an
   IANA registerd port number.
2. Both servers wait for text (the request) terminating in
   a CRLF
3. Both servers expect the request (if there is one) to be
   formatted in a particular way.
4. Both servers return plain text in response, and close
   the TCP connection.

And these are the differences that I understand:

1. Gopher will accept and respond to a blank request, with a
   default set of information, http will not.
2. Gophper sends a single "." on a line by itself to tell
   the client it is done, http does nothing similar prior
   to closing the connection.
3. Http has things like frames, multiplexing, compression,
   and security; gopher does not.
4. Http has rich, well-developed semantics, gopher has
   basic, minimalist semantics
5. Http requests are more resource intensive than gopher
   requests.
6. Http is highly commercialized, gopher is barely
   commercialized.
7. Http is heavily used and highly targeted by malicious
   users, gopher is neither.
8. Http is largely public, gopher is largely private
   (de facto privacy through obscurity.)
9. Http is used by everyone, their children, their pets,
   their appliances, their phones, and their wristwatches;
   gopher is used primarily by technical folk and other
   patient people.
10.Http all but guarantees a loss of privacy; gopher doesn't

Yeah, I know, it's not much, but that's all that is coming
to mind presently. What are your thoughts?

One last thing: what do you think a "Constrained HTTP/HTML"
experience would look like? Here's what I'm thinking,
loosely:

- A severely limited subset of HTML: <a>, <pre>, <form>,
  and <input>.
- No client-side scripting, period.
-

... and my time just ran out. I'm throwing this out there.
Let me know what your thoughts are!