Date: Thu, 6 Mar 2003 08:10:57 -0600
From: John Goerzen <jgoerzen@complete.org>
To: gopher@complete.org
Subject: [gopher] Re: Exciting PyGopherd news
Message-ID: <20030306141057.GA19899@wile.excelhustler.com>
References: <20030305225749.GA734@wile.excelhustler.com>
 <slrnb6e7d3.2hu.markj+0111@bouncing.localnet>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <slrnb6e7d3.2hu.markj+0111@bouncing.localnet>
User-Agent: Mutt/1.4i
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

On Thu, Mar 06, 2003 at 10:06:27AM +0000, MJ Ray wrote:
> John Goerzen <jgoerzen@complete.org> wrote:
> > And so, I am introducing virtual filesystem support for PyGopherd.
>  
> Why not just use lufs, avfs, hurd's translators, or any of the
> other dozens of ways to do this?

The problem with all those examples is that it is tied to the kernel.  It
would be unusable for people on a FreeBSD, or even some Linux, boxes.

I have looked at AVFS before, when I was interested in implementing a Gopher
client, and it seemed way out of date (not working with kernel 2.4 at all),
and had a combersome and ill-documented interface.

Really, the more appropriate things for this situation would be Gnome/mc
libvfs or KDE kio.  True, those are a possibility, but they would take the
project away from being pure Python, and thus introduce lots of build deps
and other nasties.  Python has a nice zipfile module, so I just used that. 
It scratched my itch :-) It was less work this way.

Though, now that we have the framework, it should not be as hard to extend
this framework to support libvfs or kio.

The other problem with libvfs and kio are that neither of them make looking
into a file completely transparent from the pathname point of view.  libvfs,
if memory serves, uses '#' to designate component parts.  kio uses something
like zip://blahblah.

Anyway, thanks for keeping me on my toes :-)