Received: with ECARTIS (v1.0.0; list gopher);
 Wed, 20 Mar 2002 16:40:28 -0500 (EST)
Return-Path: <jgoerzen@complete.org>
Delivered-To: gopher@complete.org
Received: from christoph.complete.org (unknown [168.215.193.254])
	by pi.glockenspiel.complete.org (Postfix) with ESMTP id 835863B80D
	for <gopher@complete.org>; Wed, 20 Mar 2002 16:40:28 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by christoph.complete.org (Postfix) with ESMTP id 6CBA25A39C
	for <gopher@complete.org>; Wed, 20 Mar 2002 16:40:27 -0500 (EST)
Date: Wed, 20 Mar 2002 16:40:26 -0500
Mime-Version: 1.0 (Apple Message framework v481)
Content-type: text/plain; charset=US-ASCII
Subject: [gopher] The road ahead
From: John Goerzen <jgoerzen@complete.org>
To: gopher@complete.org
Content-Transfer-Encoding: 8bit
Message-Id: <178013C0-3C4B-11D6-B325-0003930BF072@complete.org>
X-Mailer: Apple Mail (2.481)
X-archive-position: 513
X-ecartis-version: Ecartis v1.0.0
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
X-original-sender: jgoerzen@complete.org
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


I am doing some thinking about cleaning up the gopher protocol and UMN 
gopher.

These ideas are all mixed in together...

* Removing \n.\n  -- see me other message on this topic.

* Overhaul of MIME support in gopherd/gopher.  This is already in 
progress.  When done, it will use standard mime.types and mailcap files 
rather than the viewext: stuff.  (Do I hear cheers rising from the 
audience? <g>)  Moreover, it will support an "encoding" file in the 
spirit of mime.types allowing the specification of things like gzip and 
bzip2-compressed files.  You can then configure per-type decoding (in a 
manner that works and is easy to setup) on the server side, or simply 
pass the information along as-is to the client.  There will then be a 
regexp-based MIMEtype-to-gopher0type converstion table... (ie, 
text/html -> h, text/.* -> 0, etc)

* Removal of the HTTP server code in UMN gopherd.  With the advent of 
gateways such as hurg that are more powerful, I think we can eliminate 
this.  (Does anybody use it?)

* Gopher+ thoughts.  Gopher+ has not been widely implemented.  It may be 
wise to rethink this protocol -- consider it a lesson learned, and think 
about obsoleting it.

* Removal of the "extra" type character from paths in UMN gopherd (in 
most cases).  I'm not quite sure what it's used for, but I think that 
with the combination of the removal of the \n.\n and new MIME code, it 
is needed less.

* A new protocol (Gopher++?) based on Gopher0.  As an example:

1Development Projects   /devel gopher.quux.org 70

hGOPHER TURNS 10 / GOPHER 3.0 RELEASED  /3.0.0.html    gopher.quux.org 70

0GOPHER TURNS 10 / GOPHER 3.0 RELEASED  /3.0.0.txt     gopher.quux.org 70

might change to:

Development Projects	gopher://gopher.quux.org:70/1/devel   
application/x-gopherdir en_US 4132

GOPHER TURNS 10 / GOPHER 3.0 RELEASED  
gopher://gopher.quux.org:70/h/3.0.0.html  text/html en_US 3951

GOPHER TURNS 10 / GOPHER 3.0 RELEASED  
gopher://gopher.quux.org:70/0/3.0.0.txt  text/plain en_US 2000

It might be nice to eliminate the typechar from Gopher URLs.  This may 
require some other protocol changes.

Let's brainstorm.

-- John