Date: Mon, 02 Jan 2006 03:01:41 -0600
To: gopher@complete.org
Subject: [gopher] Re: PyGopherd and Gopher+
References: <20051231155642.GA9489@SDF.LONESTAR.ORG>
 <20051231164643.GB28740@katherina.lan.complete.org>
 <20051231173023.GA2684@SDF.LONESTAR.ORG>
 <op.s2pefzakvbderv@wybotnnas01-pool0-a14.wybotn.tds.net>
 <20060101165144.GA2143@SDF.LONESTAR.ORG>
From: Jeff <geph@nerdshack.com>
Content-type: text/plain; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.s2qt03v8vbderv@wybotnnas01-pool0-a61.wybotn.tds.net>
In-Reply-To: <20060101165144.GA2143@SDF.LONESTAR.ORG>
User-Agent: Opera M2/8.51 (Win32, build 7712)
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

On Sun, 01 Jan 2006 10:51:44 -0600, Benn Newman  
<newmanbe@sdf.lonestar.org> wrote:

> On Sun, Jan 01, 2006 at 08:27:25AM -0600, Jeff wrote:
>> Why don't we write a new spec which would supercede gopher+?
> In the spirit of the original design *grin* we must form a commitee to  
> solve a problem.

Let's do it then, if Mr. Goerzen approves.

> What problems need fixing? We have the campus wide informatin system. 8)
> In that movie, they said there regrets were not having venture capital.  
> :)

Here are a few of my ideas:

1)  As I wrote in my previous post, I think that reserving new tabspaces  
for information like mimetype and filesize would be a good start.  The  
file's last-modified date would also be nice.
     A menu would look similar to this,

       "1This points to a gopher  
menu%09/selector%09host%09port%09size%09mimetype".
       Where %09 is a hex-encoded tab.

     Since clients that aren't aware of the new tabspaces will just ignore  
them (as they do for gopher+) the only problem I see is with gopher URLs.   
Should the new information simply be disregarded?

2)  I think new itemtypes should be reserved for file and text uploads.   
The type of upload allowed could be defined in a new tabspace, 0 for  
textfiles, 4 for binhex, 5 for DOS binary, you get the idea.  I'm  
envisioning things like ftp gateways and bulletin board systems.

   These things may already be possible with gopher+, but to loosely quote  
the RFC1436, intelligence should be held by the server, and should not be  
required of the client.  Things like +VIEWS usually require intelligence  
on the part of the USER, who may or may not know whether he wants to  
download a file in plaintext or postscript format.  Essentially, I would  
like to streamline the important features of gopher+ to a single network  
connection and keep the syntax respectful of the original gopher protocol.

-- 
Jeff