Received: with ECARTIS (v1.0.0; list gopher); Fri, 05 Apr 2002 14:35:59 -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 DED423B80B for <gopher@complete.org>; Fri, 5 Apr 2002 14:35:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by christoph.complete.org (Postfix) with ESMTP id 15E465A411 for <gopher@complete.org>; Fri, 5 Apr 2002 14:36:00 -0500 (EST) 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> X-Mailer: Apple Mail (2.481) X-archive-position: 567 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

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