[gopher] Re: Pygopherd nearing gopherd replacement

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

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