[gopher] Re: A Sunday morning diatribe

["Matthew Holevinski" <eylusion@xxxxxxxxx>]

What's wrong with just 2 item types?

Ascii and Binary--Ascii you view and Binary you download, do with as
you wish files.
I mean I kind of agree with a few of the others like the CSO searches
and stuff but do
they really need their own item type? I mean smart server dumb client,
their will need
to be a way to pass that data to the server "agreed" but if the best
way to do that is
item types then so be it.

I'm more concerned not with whether or not our gopher clients can view
jpegs or pdf's.
But what we utilize our gopherspace for, more from a philosophical
standpoint. I mean
it's great that we discuss these technical details of a protocol
mostly forgotten, and
carry the weight of it's development on our shoulders and
wholeheartedly care about
what happens to it and what is to be done with it.
,
But personally whether you provide up links in your directory
structures or bounce
all your content off other services like an old 1992 portal website
would do, is not
the case with me. It's what content are we posting, what are we doing
with gopher.

We could build up something really special but no one will notice if
there isn't anything
they can do with it, like the progression of first person shooters,
you can only shoot
something or someone so many times before it's repetitive, so all new
games just have
more detailed textures, and fuzzier particle explosions.

I ask what will we do with these server's, hypothetically after all of
the programming jargon
is satisfied, and their are no more qualms about architecture. What
information will we
actually provide to one another, someone just mentioned you can't
really upload information
to a gopher in gopherspace, which kind of sucks but if this was meant
more as data retrieval
system namely text in a network filesystem. What do we all want to
contribute, that is what
sparks my curiosity.

Matthew Holevinski

On Sun, Jul 20, 2008 at 5:12 PM, John Goerzen <jgoerzen@xxxxxxxxxxxx> wrote:
> 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 ;-)
>
>
>