[gopher] Re: A Sunday morning diatribe

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

JumpJet Mailbox wrote:
> Please allow me to indulge in a bit of Sunday morning musing and
> pontificating.  Thanks.
> 
> MINDSET:
> 
> Comparing the WWW to Gopher is "wrong thought".  It starts the
> conversation from a faulty predisposition and it never entirely
> breaks free.  The WWW was designed in isolation from, and is in no

I'm not so sure about that.  "WWW" is a loose term.  It's a set of a few 
common technologies: the idea of a multiprotocol URI; support for HTML; 
and commonly-found support for HTTP, FTP, and Gopher as underlying 
transport protocols.  I would say that the WWW folks were certainly 
aware of Gopher.

> way associated with, Gopher.  Even saying that the WWW does things
> better than Gopher is a misnomer. Yes people may claim that for the

Well, again the two are not completely separate, but yeah, that's a good 
point.  "Different" perhaps.

> Gopher was developed by a University as a way to provide their
> students a way to access the Universities data in a manner that was
> superior, both in presentation and safety, to the "File Transfer
> Protocol" (FTP).  Gopher is actually a SuperSet of Anonymous FTP!!!

Actually, no.  It's a subset of it in almost all respects.  FTP provides 
support for obtaining the size of files in advance; binary stream and 
record-mode transfers; transferring only the last parts of a file; etc. 
  Gopher supports only a subset of that, but adds a more robust 
standardized directory listing.  Gopher is also the more simple protocol 
by far.  FTP is pretty complex, even today.

Gopher also is one-way, and does not permit uploading, modifying 
permissions, renaming, etc.

> When you start a conversation comparing Gopher to FTP, this is "right
> thought".  Now the conversation takes on a different tone, and the

My understanding was that UMN wanted a network-wide filesystem.  That 
is, a global NFS.  I don't know that this has ever been realized.

> RFC 1436:
> 
> The first paragraph says it all:  "It (RFC 1436) does not specify an
> Internet standard."
> 
> This is a very important statement.  From a historical standpoint, it
> confirms that Gopher was developed independently, away from the

No, that has nothing to do with how Gopher was developed.  It has 
everything to do with what sort of RFC it is and what sort of process it 
has taken through the standardization bodies.

> mainstream "Internet" development team (CERN being the 800-pound
> gorilla).  It also, unfortunately (or fortunately, depending on your
> perspective), means that the Gopher standards have yet to be written
> in stone.

... like all other Internet standards.

> At this time, it looks as if participants to this NewsGroup, and the
> operators of the Super Gopher Servers, are the ones to whom the
> mantle of determining "best practices" fall.

Completely agreed!

> servers so that Clients from ALL platforms (not just Unix-based ones)
> can take full advantage of the data presented (just a your Web site
> should work with Lynx and WebTV).
> 
> For example:  While most Unix-based platforms do not use
> "dot-plus-three" file content description extensions; Tandy, DOS, and
> Windows platforms DO.  Would it be such an intolerable burden to
> include file extensions when you post a file on Gopher, even if you
> and your friends may not use them?  It sure would be helpful to
> others if you did.

I think pretty much everybody does, don't they?

I certainly don't think it makes sense to mandate it, and especially it 
does not make sense to mandate a limit of 8.3 filenames.  The game of 
what filenames are used is never-ending, and you can find systems with 
6-character, 12-character names, or then the Macs with resource forks 
and Finder info yet too.

> the Gopher protocol, for transmitting public consumption Gopher.  Why
> not use Port 70 for your server, even if you could do otherwise?
> Some reasons include: * For nearly all Server operators, using Port
> 70 is NOT an intolerable burden. * Port 70 has been reserved by IANA
> for your use, so there are no "conflict" considerations. * Many
> Routers are pre-configured OPEN on Ports 21, 70, and 80 (but block
> other Ports). * Many Clients (and Servers) have been improperly "hard
> wired" to look only to Port 70.  Not using Port 70 would therefore
> prevent a large contingent of users from accessing the information on
> your Server.

But there is the problem that Gopher doesn't support virtual hosting.  I 
think a port number should be a transparent technical detail.

> What seems to have been overlooked is that there are ALREADY links to
> the more broad-based information stockpiles.  They are listed in
> "Gopher Jewels 2".  However NO ONE has sent a single link to be
> included in Gopher Jewels 2 (even though contact information is
> included and link suggestions are actively solicited).  Come on
> people... send links to these repositories.  This way, if you wanted
> to link "broader", you could just include the appropriate GJ2 URL!

One problem with that is that if your server goes away, poof, so does 
the utility.  I don't even know who you are... why should I trust that 
your server will still be there in a few years' time?

The same can be said about my server, Cameron's, and all of ours.  We 
are part-time enthusiasts.  And I think this discussion is focusing on 
the wrong areas, to.

> Another example: There have been endless debates about Ports and Item
> Types and Presentation appearance, and File handling.  Yet no one
> seems to have looked to see what is actually being supported by the
> existing Gopher Clients and Servers.  Come on people... there are
> only a handful of Clients and Servers, almost all being archived on
> JumpJet gopher://home.jumpjet.info/11\Begin_Here
> 
> Grab some, load them on your computer, do a few quick tests, and
> write a paragraph or two review about them.  I will post these
> reviews on JumpJet, so this way everyone will actually KNOW what is
> or is not supported!!!

And this, I think, is begging the question: what exactly is it that we 
are trying to achieve now?

I was excited back in 2000 when I asked UMN to GPL the UMN gopher 
source, and they did.  Since that time, we've seen at least two major 
new gopher server projects, one major new gopher client project, and two 
major new gopher spidering projects, among others.

Yet despite some early small successes, I'd say it's fair to say that 
gopher has become ever more marginalized, especially having lost default 
support in major web browsers.

It is healthy for this community to have a disucssion on what gopher 
should be.  This discussion should start with our goals for the protocol 
itself.

One of the major problems (perhaps THE major problem) with HTTP and all 
the associated protocols like SOAP, XML-RPC, etc. is complexity.  Well, 
HTTP *can* be a simple protocol, but it's got so many ins and outs that 
neither modern clients nor modern servers can be all that simple.

Part of me wonders whether it is time to prepare Gopher++ -- an enhanced 
subset of HTTP.  We could toss out all the form-encoding nonsense, the 
content-transfer-encoding tripe, the POST PUT DAV stuff, cookies, 
escaping, most headers.  Accept Host: in the request and place 
Content-Type in the response.  Maybe support Range.  Define a standard 
directory representation that is simple in the tradition of the current 
type 1.  (Maybe a header in the request indicates suport for these; and 
fall back to HTML otherwise.)  Get rid of the type as part of the URL.

Gopher would live up to its roots, its simple ideals, and yet embrace a 
few features that it really ought to have these days -- and gain 
compatibility with tons of existing software.

But then again somebody would have to write it...  so here's my Sunday 
diatribe, that may or may not make any sense ;-)