Received: with ECARTIS (v1.0.0; list gopher); Fri, 05 Apr 2002 17:17:12 -0500 (EST) Return-Path: <jgoerzen@complete.org> Delivered-To: gopher@complete.org Received: from christoph.complete.org (pcp947166pcs.cstltn01.in.comcast.net [68.58.145.248]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id EF2973B80B for <gopher@complete.org>; Fri, 5 Apr 2002 17:17:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by christoph.complete.org (Postfix) with ESMTP id 6FAEA5A408 for <gopher@complete.org>; Fri, 5 Apr 2002 17:17:14 -0500 (EST) Date: Fri, 5 Apr 2002 17:17:11 -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: <20020405214239.CHDN4902.tomts24-srv.bellnexxia.net@[209.226.175.18]> Message-Id: <DFF2BC75-48E2-11D6-857D-0003930BF072@complete.org> X-Mailer: Apple Mail (2.481) X-archive-position: 569 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 04:42 PM, Ralph Furmaniak wrote:

> Looks like that's cleared up. > I still think that the output should be post-processed. This is > especially an issue when the server can do http output. Either way, if > there is no pos-processing then the executable will have to know the > hostname, port, the documentroot, whether it should be formatted for > gopher0,gopher+,http.

Well, you can just tell it that this directory cannot do gopher+. I use this trick with UMN gopherd on quux where I have some files-acting-as-directories. (Still a problem for HTTP).

> For this you would probably need to set environment variables, and > then make a library that is accessed by the executables (unless you > want each programmer to remake this on their own). PLus, this would > limit the possible languages to those with libraries.

In pygopherd, there is just such a library. Each "handler" receives a protocol object when it is instantiated. These protocol objects have a uniform interface for rendering directories in a fashion that is powerful enough for all gopher protocols and HTTP and is flexible enough for various types of handlers. The handler does not care what protocol is being used. (It can find out, but there's no need to.)

> Another possibility is for the script to signal back to the server what > it is printing, but I think that the extra character is enough.

Yeah, and that's icky anyway.

> How is it better to have the character at the end?

Because then relative links in documents work for HTML files -- and even in other files. It's a big problem to try to serve up HTML files with these files. The HTML file may live at h/papers/index.html and all its graphics at g/papers/index.html. An IMG SRC of "header.gif" will reference h/papers/header.gif instead of g/papers/header.gif. Referencing "./" to get the current directory will fail (it'll get h/papers rather than 1/papers), etc.

Not having this problem is a Good Thing (TM).

-- John