The true spirit of gopher
-------------------------

What is the "true spirit of gopher"?  Its "heart and soul", the deep,
conceptual commitment which distinguishes it from other protocols, in
particular from the web?

Chances are good you have the term "plain-text" on your lips right
now, and nobody could blame you for it, given the way that we all
(myself included) talk casually about gopher and what makes it so
great.  But if you think about it, it's actually a bogus answer.

Every webserver I've ever used will very happily serve a plain-text
file.  It'll include a "Content-type: text/plain" HTTP header in the
response, and your browser will recognise this and apply absolutely no
formatting or styling at all and just show you plain text.

You could build an entire website (would it *be* a website, in fact?)
out of plain text files.  You could link between them with reference
numbers and URLs, exactly like we do in the phlogosphere, and your
readers could highlight those URLs and paste them into their browser's
address bar.  The result would be a navigation experience very similar
to reading phlogs with a client other than VF-1 (which will extract
the links into a menu for you to avoid the need to highlight).  You
could have no index.html file at the root of your webspace and rely
instead upon the server's automatically generated directory listing -
which is quite a bit like a gopher menu without the (unofficial, not
in RFC1436) i item type.  If you did this using a webserver that
didn't serve cookies or any other objectionable stuff, then that's
pretty much a pure RFC1436 gopher experience right there, over HTTP
and using a web browser.  There is no substantial difference in the
user experience.

The inverse is *almost* true, too.  The h item type isn't in RFC1436,
but it is widely used and widely supported and has, I would argue, the
same de-facto standard acceptance as the i item type.  Perhaps a
little less, but not much.  With even a vaguely modern gopher server
and client, you could have a gopherhole full of HTML files.  Some
clients might not handle it so well but lynx, say, certainly would.
You could *almost* avoid gopher menus entirely, and instead use
<a href> tags to link from item type h document to item type h 
document - the gopher:// URL scheme has its own RFC (RFC4266), after
all.  Plenty of phloggers use gopher to serve the occasional image or
sound file.  Serving HTML is, from a protocol perspective, not one
iota less legitimate.  You do need to have *one* gopher menu (if a
client sends an empty selector to a server, the response must be a
menu), which is why there are some "almost"s above, but everything
else could be HTML.

You *could* do either of the above, but nobody does (I might try the
first one using shizaru after a few beers some time...).  At the end
of the day, this comes down to something like "community expectation"
or "social convention".  Gopher = plain-text, HTTP = HTML is *not* a
technical requirement of either protocol, it's "just" a norm.

So, what is the *real* heart and soul of gopher?  An actual,
honest-to-goodness, protocol-level conceptual distinction between
gopher and the web?

I would argue that the answer is "separation of content from
navigation".  The first two gopher item types, type 0 and type 1, are
for documents and menus, respectively.  They are, explicitly,
different *kinds* of things from the protocol's point of view.  In pure
RFC1436 gopher, there is no i itemtype, so menus are *just* lists of
links to either documents or other menus.  Documents fundamentally
*cannot* link anywhere, in anything other than a clunky manual way by
including URLs in a text document.  This dichotomy is crystal clear.

This dichotomy also has no analogue on the web.  Webpages combine
content and navigation via in-line hyperlinks.  You can of course
build a webpage with no <a href> tags which is a navigational
dead-end, just like a "pure" item type 0 gopher document.  And you
could build a web page which was just a <ul> list of <a href> tags
with no <p>s or <spans>, which would be something like a "pure" item
type 1 gopher menu.  But they would both actually be the same kind of
thing: HTML documents.  The browser would request them both in the
same way, the server would serve them both in the same way, and they'd
get parsed in the same way - and all in exactly same way as you could
do something which was half way between these two extremes.  There is
no conceptual distinction between content and navigation to be had,
there is only HTML.

This difference between gopher and the web is *much* more deeply
engrained in the actual protocol specifications than the plain-text
vs HTML difference which is so salient to the end user.

Now that we've uncovered the true spirit of gopher, the natural
question, for those participating in the on-going discussions about
new gopher-inspired protocols, is whether or not this idea is one that
the gopher community really cherishes and which should be preserved in
the Ultimate New Protocol of Truth and Glory.

I would argue that, in fact, the not-at-all-enforced-by-protocol
community norm of using only plain-text is *much* more precious to
most modern gopher users than the content-vs-navigation distinction.
The proof of this is that nowadays so many folks are deliberately and
unapologetically erasing that very distinction by using item type 1
for their entire gopherhole, serving all of their actual content as
item type i menu lines.  Anybody who has read RFC1436 will tell you
that this is a flagrant semantic abuse of gopher; there's just no
wiggle room on that question.  Anybody who has tried to write a gopher
client which treats items types 0 and 1 "too" differently (like very
early versions of VF-1) will tell you that this eventually causes
problems if you don't want to play hard ball and declare that
gopherholes doing this won't be properly viewable in your client.

But at the end of the day, building type 1 only gopher holes pretty
much just works, and it *does* offer a nicer user experience by
letting you embed immediately usable links right in the middle of your
phlog posts.  So people do it, and that includes well-known and
well-loved gopher users and advocates like Tomasino, who is
unquestionably a great force for good in the gopherverse.  There's
plenty of evidence out there that a lot of Gopher enthusiasts don't
actually *want* a protocol that divides sharply between navigation and
content.  They just want to be able to serve plain-text with
hyperlinks anywhere they like, via a bare bones protocol that doesn't
support tracking and other unpleasantries.  Something like "HTML with
only the <a href> tag, over HTTP/0.1".  I think that's all *I* want.
But it doesn't exist, and gopher does, so we use gopher and the hard
line between menu and document comes along with it.  Some people learn
to live with that hard line, some people fight against it, and some
people embrace it *too* much, creating overly-hierarchical,
user-unfriendly gopherholes where things live deep in
phlog/year/month/ sub-sub-sub menus which are inconvenient to casually
browse.  Very few of us, I suspect, come here *for* this hard line.
Most probably don't even actually give it much thought.

Arguably, a protocol without this hard line has a stronger claim to
being minimalist and simplistic than one with it, all else being
equal.  What could be simpler than everything being the same kind of
thing?