Mime-Version: 1.0
Message-Id: <p05010412b8d273621bed@[205.189.158.32]>
In-Reply-To: <F8A387F6-4810-11D6-857D-0003930BF072@complete.org>
References: <F8A387F6-4810-11D6-857D-0003930BF072@complete.org>
Date: Thu, 4 Apr 2002 16:19:06 -0500
To: gopher@complete.org
From: Robert Hahn <rhahn@tenletters.com>
Subject: [gopher] Re: Pygopherd nearing gopherd replacement
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


You want comments?

I've a question. does that count? :)

How fast is it relative to the C version?

My guess is that the main bottleneck is the disk access, so it's 
probably not much slower, right?

-rh

>Hello,
>
>Pygopherd is nearing feature-completeness relative to UMN gopherd.
>
>Today, I have implemented support for UMN-style .Links, .names, etc. and
>.cap/ files/dirs.  The implementation is believed to be an *exact* clone
>of UMN support (by reading C code and rewriting it in pygopherd),
>including bugs.  I have tested pygopherd over the quux.org site -- which
>contains UMN menus of every size and shape -- and it is running fine
>thus far.
>
>The HTTP support has been enhanced as well.  There is now a nice-looking
>icon system for HTTP.  Pygopherd will answer both HTTP and Gopher
>requests on the same port.
>
>The remaining items to complete are:
>   * Support for "filesep" virtual folders
>   * Support for Unix MBOX virtual folders.
>   * Caching of gopherdirs
>   * Specifying of hostname/port of server [easy]
>
>Once these are complete, I intend to stress-test it by switching
>quux.org over to pygopherd.  Assuming no bad result, version 1.0 of
>pygopherd will be released.
>
>After that, I will consider making pygopherd the default gopherd in the
>UMN gopher tree, possibly with a configuration migration tool.  Comments
>welcome.
>
>Pygopherd 0.4 is available at gopher://quux.org/1/devel/gopher/Downloads
>or http://quux.org/give-me-gopher/