[gopher] Re: Pygopherd nearing gopherd replacement

[Wolfgang Zekoll <wzk@xxxxxxxxxxxx>]

At 09:32 05.04.02 -0500, John Goerzen wrote:

>On Thursday, April 4, 2002, at 06:37  PM, Ralph Furmaniak wrote:
>
> >> Pygopherd also does not add
> >> an extra (or "second" if you're using URLs) type character like UMN
> >> gopherd does.  Because it figures all this out itself, that is
> >> unnecessary.
> >
> > This does have its uses.  For example an executable must be able to
> > return
> > either a plain file or a menu (gophermap format).  If you include the
>...
>Actually, I believe that including it makes the code more complex.
>Since the client already knows what sort of document it's getting,
>there's no real need for the server to know at that time.  Especially
>now that we're doing away with \n.\n.

When I tried to drop the leading type character in the gopher selectors
I discovered the following problem.  The server receives the request

         /fooFsomedata

with `F' being a tab character.  Now the question for the server is if
`/foo' is of type 7 or not.  In the first case `somedata' is the query
string in the second it's a gopher+ attribute.

To answer this question and to continue the selector parsing the server
must first get the type of `/foo'.  This is possible but I prefer the
server to have a clear understanding of the selector before doing
anything else like analysing the request and the addressed item.  In
other words, I want to make the selector interpretation independent
from the available data.  Here the leading type character simply helps
the server to see how the whole request should be interpreted.

Regards

Wolfgang Zekoll