Received: with ECARTIS (v1.0.0; list gopher);
 Wed, 20 Mar 2002 18:00:03 -0500 (EST)
Return-Path: <rhahn@tenletters.com>
Delivered-To: gopher@complete.org
Received: from quarry.com (mail.quarry.com [205.189.158.4])
	by pi.glockenspiel.complete.org (Postfix) with ESMTP id 0FB0A3B840
	for <gopher@complete.org>; Wed, 20 Mar 2002 18:00:03 -0500 (EST)
Received: from [205.189.158.32] (205.189.158.32) by quarry.com with ESMTP
 (Eudora Internet Mail Server 3.0.1) for <gopher@complete.org>; Wed, 20 Mar
 2002 18:00:03 -0500
Mime-Version: 1.0
X-Sender: rhahn@mail.quarry.com (Unverified)
Message-Id: <p05010406b8bebf1c74fa@[205.189.158.32]>
In-Reply-To: <20020320165126.A2219@mothra.dyndns.org>
References: <178013C0-3C4B-11D6-B325-0003930BF072@complete.org>
 <20020320165126.A2219@mothra.dyndns.org>
Date: Wed, 20 Mar 2002 18:00:12 -0500
To: gopher@complete.org
From: Robert Hahn <rhahn@tenletters.com>
Subject: [gopher] Re: The road ahead
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-archive-position: 517
X-ecartis-version: Ecartis v1.0.0
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
X-original-sender: rhahn@tenletters.com
Precedence: bulk
Reply-to: gopher@complete.org
List-help: <mailto:ecartis@complete.org?Subject=help>
List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-ID: Gopher <gopher.complete.org>
X-List-ID: Gopher <gopher.complete.org>
List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe>
List-owner: <mailto:jgoerzen@complete.org>
List-post: <mailto:gopher@complete.org>
List-archive: <http://www.complete.org/mailinglists/archives/>
X-list: gopher


<massive snip>

>Well, a while back I think there was a thread where we were talking
>about what makes gopher gopher, and people were talking about avoiding
>reimplementing HTTP in terms of gopher, etc.
>
>When making protocol changes, I think this question is important:
>"what is gopher to you?"  What should gopher be able to do?  What
>areas should it not mess with?  Which parts of Gopher+ were good, and
>which were just lousy ideas?
>
>Basically I'd like to know what we want Gopher to be so we can make
>protocol changes to reflect expected functionality.  What I don't want
>to do is make protocol changes and end up with a *new* batch of
>completely unused functionality with the added benefit of having
>broken all backwards compatibility.

This is why I like gopher now:
1) it's *extremely* lightweight - there's almost nothing there.
2) It's claimed to be *extremely* fast.
3) You can pick it up in about 2 seconds. Well, maybe 20 minutes. But 
the important thing is, you're not required to learn how to do 
html/javascript (a discipline I've been practicing for 7yrs now) or 
other tricky stuff.

The biggest problem that I see is that it's hard to extend. Adding 
mimetypes would fix some of that.

I wish gopher would permit people to send data back to the server. 
One reason why I think the web exploded in #'s of users is that there 
was two way interaction (through html forms). Amazingly enough, email 
has that very same quality - and look how popular *it* is. Gopher is 
a one-way street, more or less. For those who'd disagree, sending 
requests could conceivably be sending data, but there's too little 
flexibility in the kinds of data to send back.

Does it solve any problems that http doesn't? Right now, I believe 
the answer is no, not really.  I'd love to hear comments to the 
contrary, though...

Are there problems that neither http or gopher addresses? Pick one or 
two of those (especially if it's easy to explain to laypersons so 
they see it as a 'burning need'), solve them really well, and we 
could be on the road to bigger mindshare...

-rh