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