Date: Fri, 5 Apr 2002 09:32:19 -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: <3CACE3A1.464BE377@sympatico.ca>
Message-Id: <EF40ADB8-48A1-11D6-857D-0003930BF072@complete.org>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


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

Well, unless you pass the character to the executable, how does it 
help?  If you pass it to the executable, you might as well just use 
something else.

> character you can also do things such as using type 1 for a file and 
> have it
> read as a gophermap menu.

I've sometimes used this trick with textfiles even :-)

> This character is also used to signify mail spool files.

UMN gopherd automatically recognizes the From lines and so really 
doesn't need the extra type character.  I intend to do that the same.  A 
mbox will just be a type 1 object as far as anything is concerned.  The 
mbox handler does not need to be told that it's getting an mbox, it just 
knows :-)

> Including the type character can make the code somewhat (albeit not 
> much)
> simpler and does not cause any problems that I am aware of.

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.

-- John