Date: Fri, 5 Apr 2002 14:36:00 -0500
Subject: [gopher] Re: Pygopherd nearing gopherd replacement
Content-type: text/plain; charset=US-ASCII
Mime-Version: 1.0 (Apple Message framework v481)
From: John Goerzen <jgoerzen@complete.org>
To: gopher@complete.org
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <20020405185838.LCJZ19941.tomts19-srv.bellnexxia.net@[209.226.175.18]>
Message-Id: <5BF242A8-48CC-11D6-857D-0003930BF072@complete.org>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Friday, April 5, 2002, at 01:58  PM, Ralph Furmaniak wrote:

> The executable already knows what it will return, and the person making 
> the menu knows what it will return.  Suppose you have script 'foo' that 
> reads an archive and displays a menu.  You also have a script 'bar' 
> which just serves files from the archive.  Suppose the server does not 
> receive the character.  If it just prints the results, then gopher+ and 
> http browsers cannot access foo.  If it automaticlly formats it, bar 
> will look strange or be corrupted.

Are you saying that the Gopher server process would post-process the 
output from foo and re-render it in some fashion?

If so, then yes, you would have to know this information. However, I 
would suggest placing it at the *end* of the selector rather than at the 
start.  Makes things cleaner IMHO.

I am not currently envisioning scripts returning anything that is 
post-processed by the gopher server.  I figure, right now, that is not 
the job of a gopher server.  HTTP clients using pygopherd running these 
scripts will be SOL, but all gopher browsers will be fine.  HURG would 
be good for this situation.  (Note: I reserve the right to change my 
mind :-)

As long as the server does not need to post-process the data, there is 
no need for the server to know the type of data (this is specified in 
the menu and so the client knows.)  Perhaps this is why we have been 
miscommunicating all the time -- you assumed the server would 
post-process and I assumed it would not?

> You could of course have the script examine the gophermap,link,cap 
> files to determine the type, but this makes things more complicated 
> especially if 'foo' and 'bar' are one and the same script.  It is 
> especially more complicated if the original menu was itself a script.

Yes, that's ugly.

> This is not a problem in umn gopherd, since it automatically assumes 
> that executables are text/plain.

You can still make them return menus if you like, just set Type=1.

-- John