[gopher] Re: Item Type Suggestions

[Jay Nemrow <jnemrow@xxxxxxx>]

I am at an impass because I want to actually respond to you, but I find 
what I am thinking colored highly by the wonderful response by Matthew 
Holevinski.  I guess  I will be responding to his post (that echo my 
thoughts concerning Gopher so well) in both emails, just to keep the 
threads going.

I find myself agreeing with everything you say in a technical way.  I 
absolutely agree that life would be far better if people were concerned 
with workmanship.  I don't want to encourage anything bad, but just to 
point out that if we make significant changes to the protocol with the 
intent of keeping up with the times, we cease to talk about gopher and 
are may be planning for some new creature.  I am on this list and have 
run a gopher server for over three years because its basic nautre serves 
my needs in a way that pleases me.  The "evolution" of gopher is 
meaningless to me: it suits me fine the way it is.  Therefore, my 
purpose in this discussion is really only to ensure that what ultimately 
happens is backwards-compatible with the very basic root of RFC 1436, 
which described the original protocol.  Basically, I desire that my 
oldest gopher client (Lynx, at the moment) still work with the servers 
that proport to be gopher servers in the future.

It makes me think of all the brew-ha-ha about what Linux must do to 
compete with Windows that I read in the trades.  It is as if Linus 
Torvalds sat down in 1991 and said "I desire to compete with Microsoft 
Windows, therefore I will make Linux."  I have read the original posts 
that announced what would become Linux, and it seemed nothing more than 
a college student wanting to make a free Unix clone, get some help with 
the effort, and share the results with everyone, which had nothing to do 
with Microsoft or Windows.  I think Linus et al did a wonderful job with 
Linux and he accomplished his goals very well, to the point that Linux 
is now the standard that Unix often follows and all sorts of interesting 
stuff is created to work with it.  I hope we are not trying to tie 
Gopher's future with competing (or keeping up) with 
http/html/ajax/flash, which doesn't seem to be the intent according to 
the founding document.  I read simple, simple, simple finding and using 
text and binary files all through it.  

I may be repeating myself, but my attraction to gopher is its simplicity 
in programming, both on the client side and on the server side.  I was 
reading the original protocol itself (RFC 1436) and I find myself drawn 
to the original intents of it, that anyone could throw up or write a 
server on their desktop computer and contribute texts and files to the 
larger gopherspace.  Also, anyone could, with basic programming ability, 
put together a very simple and useful gopher client.  I would prefer 
that we didn't stray from these intents, as I feel this is at the heart 
of the protocol and its design.  If we wander away from this, we are 
probably talking about something other than gopher, which might require 
a new protocol name and mailing list!  (I propose Porky Pig if things 
continue unabated.)  If I am forced to alter my gopher servers or 
clients to remain compatible with some new standard, I am not coming 
along for the ride.  For me, "doing this right" involves honoring the 
original protocol which requires no thought in my mind - obey the 
original protocol and don't force changes that would break the 
functionality of existing gopher clients.

I don't see anything particularly in what Cameron is doing or in what 
you are saying that violates RFC 1436.  Hopefully, we are just 
discussing additional menu item types that we might want to standardize 
on.  As long as changes don't break the ability of Lynx (in my case) to 
access the bulk of the content on gopher servers, I have no problems 
with them, although I think it would be a terrible shame to basically 
hide most content on a server  because new types cannot be used by old 
browsers.  I want my content to be viewed by the largest audience 
possible and that means that I adhear strictly to the oldest established 
version of the protocol and that I have a http bridge to allow those who 
don't use a gopher client to access my stuff, arcane though the 
interface may seem.

I feel like RFC 1436 was designed to be extensible so it could 1) keep 
up with newer file types that would emerge, and 2) to allow certain 
certain groups the ability to create extensions that filled their needs 
(such as CSO bridges), knowing that special servers and special clients 
may have to be created to handle those extensions.  Though the protocol 
allows for these possibilities, I personally avoid them because 1) there 
is a newer technology (www) that most newer content is heavily skewed 
toward and a lot of it doesn't easily fit file/folder paradigm that is 
at the heart of Gopher, and 2) I think splitting what few people who 
still are involved in the Gopher community into different camps 
according to what specialized servers/clients they lean toward would be 
disasterous.  At some point, I feel there must be a line drawn in the 
sand, as it were, as to a basic standard - I have personally chosen a 
subset of the types spelled out in RFC 1436, mostly 0, 1, and  7, as 
discussed in "3.4 Modualr addition to services".  Since binary files are 
so important (the whole world isn't text), I will add 9.  I am (or want 
to be) an adherent to Sections 3.5 (especially the part about how a 
client handles types it doesn't know) and the entirety of 3.6 
(intelligence is carried by the server).  Section 3.7 speaks of special 
purpose servers "(beyond the normal gopher server)" and I don't want to 
fall into the trap of specialisation, which I fear we may do by creating 
servers that only work well with "modern"clients.  The www way has 
become stupid servers trying to serve "smart" clients - how many of you 
have altered a web page so that it will display well in a certain brand 
of browser?  Excuse my yelling but GOPHER SHOULD NEVER FALL INTO THAT 
HTTP/AJAX/FLASH/WHATEVER TRAP OF PULLING INTELLIGENCE AWAY FROM THE 
SERVER!  READ SECTION 3.6 - IT IS THE ESSENCE OF GOPHER!  I want to be a 
0,1,7, and 9 person and when we go beyond that, you lose my interest, 
really.

I am not saying that Cameron or anyone else SHOULDN'T specialize and add 
new types.  They can if they like.  My servers (like everyone else 
around here, I am writing one, too) will stick with the basics and not 
get drawn in by the "be all things for all people" siren-song. As long 
as OverbiteFF can handle 0,1,7, and 9 well, he can make a 
toliet-flushing data item as far as I care.  My comments all began in an 
effort to preserve the 0 data type for basic text files as opposed to 
some virtual type that includes Microsoft .doc and .rtf or other text 
replacements, which I was concerned would break older clients.  How the 
request exploded to my feeling the need to present diatribes like this 
escapes me just now, so I will end shortly.

There are other forums to discuss programming style and other periphrial 
topics and I will (hopefully) stop talking about such things here.  I 
will try to keep my future comments strickly to Gopher.  Sorry for the 
inconvenience.  

JumpJet Mailbox wrote:

>Life would be far better if the average person had more pride of workmanship!
> 
>We are not talking about a major programming effort here.  Making a good 
>Gopher program is far less complicated than (I would estimate) about 80% of 
>the programming currently being done by both amatures and professionals.  The 
>creator of the Acorn Gopher Client for example, claimed that he built the 
>Acorn Client in less than 4 hours.  
> 
>Today, there is almost NO excuse why a single person could not build a near 
>flawless piece of Gopher Software in about a week or two.  The real issue here 
>in NOT "can it be programmed quickly and relatively bug-free", but rather 
>"what FEATURES are to be incorporated".  
> 
>We are not in a market competition that requires rapid software release to 
>stay ahead of the competitors, nor are profits hinging on the rapid realease 
>of software.  We are instead striving to get more uses interested in the 
>Gopher Protocol.  The critera for that goal is software with "Features People 
>Want", and "Relatively bug-free performance".  These goals dictate doing the 
>job "Right The First Time" (NOT quick and dirty programming). 
> 
>We are only likely to have a potential new Gopher Protocol user examine the 
>protocol and software ONCE.  If he doesn't see what he needs (or he sees 
>slapped-together-software), it is unlikely that he will ever examine the 
>protocol again.  
>
>--- On Mon, 7/14/08, Jay Nemrow <jnemrow@xxxxxxx> wrote:
>
>From: Jay Nemrow <jnemrow@xxxxxxx>
>Subject: [gopher] Re: Item Type Suggestions
>To: gopher@xxxxxxxxxxxx
>Date: Monday, July 14, 2008, 3:22 PM
>
>All productive programming is Quick and Dirty.  Funny that you use
>that Phrase, as QDOS (Quick and Dirty Operating System) was the basis
>of MSDOS that stomped out competition quite effectively, simply
>because it came to market first (at a good price-point), though it was
>technically inferior in many ways.  If you ponder too much, consider
>all the angles, you will be non-competitive and never get out a
>product before the market is already saturated or has blown past you.
>
>You can never do it right the first time.  It only gets closer to
>"right" as you read your market and make changes to meet needs
>(sometimes requiring a complete recoding of things you never
>considered that were important).  Even though Gopher is not a
>commercial product (sure sounds like some people are thinking along
>these lines though - "We have GOT to do this right"), it might be a
>desire that it meets the needs of a group of gopher-wranglers.  New
>versions make that happen, as opposed to some mystical, perfect
>"first-effort" implementation.
>
>sounds like you had a lot of work incident to y2k.  If the originial
>programmers had "gotten it right" initially, your job might not have
>existed.  Perhaps we should be glad for unperfect things that require
>our effort in order to get "better" or to "fix" things.
>
>Jay
>
>On 7/12/08, JumpJet Mailbox <jumpjetinfo@xxxxxxxxx> wrote:
>  
>
>>Thanks to the dilligent effort of countless untold computer specialists
>>    
>>
>(including myself) over a period of several years, our efforts were indeed
>successful (but a royal pain none the less).
>  
>
>> Fixing Gopher issues I'm afraid, won't generate quite the
>>    
>>
>response from the community, so we have GOT to do it right the first time... NO
>"quick-and-dirty" programming!
>  
>
>>--- On Thu, 7/10/08, Avery M. <averym@xxxxxxxxx> wrote:
>>
>> From: Avery M. <averym@xxxxxxxxx>
>>
>>Subject: [gopher] Re: Item Type Suggestions
>> To: gopher@xxxxxxxxxxxx
>>
>>Date: Thursday, July 10, 2008, 4:44 PM
>>
>>
>> You mean the non-bug?
>>
>> On Thu, Jul 10, 2008 at 4:34 PM, JumpJet Mailbox
>>    
>>
><jumpjetinfo@xxxxxxxxx>
>  
>
>> wrote:
>> > Expediency is what always gets us into trouble.  Does anyone
>>    
>>
>remember the
>  
>
>> Y2K bug?
>>
>>
>>
>>
>>
>>    
>>
>
>
>      
>
>  
>