[gopher] Re: Pygopherd nearing gopherd replacement
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
Reply to: