[gopher] Re: PyGopherd and Gopher+

[Jeff <geph@xxxxxxxxxxxxx>]

On Sun, 01 Jan 2006 10:51:44 -0600, Benn Newman  
<newmanbe@xxxxxxxxxxxxxxxx> 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