Date: Sat, 12 Jan 2002 15:11:44 -0500
From: David Allen <mda@idatar.com>
To: gopher@complete.org
Subject: [gopher] Re: GopherFS implementation questions
Message-ID: <20020112151144.A29753@mothra.dyndns.org>
References: <87y9j3fqy7.fsf@complete.org>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <87y9j3fqy7.fsf@complete.org>;
 from jgoerzen@complete.org on Sat, Jan 12, 2002 at 11:56:48AM -0500
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Sat, Jan 12, 2002 at 11:56:48AM -0500, John Goerzen wrote:
> 
> Hi,
> 
> I found a project on SourceForge called FUSE.  It provides a very easy
> way to implement userland filesystems for Linux and -- most important
> -- it is actively maintained and works with current kernels.
> 
> So, I started hacking on a gopherfs with FUSE.  However, I'm coming up
> with some design questions that I'd like help with.
>
> Brainstorms, thoughts, etc. are welcome.

FWIW, I wanted to note a few things I had problems with early on in
writing gopher software (The FORG - http://opop.nols.com/forg.shtml).
They may be applicable to the filesystem layer view of gopher, at
least for possible problems to avoid.

Many of the servers out there seem to be UMN gopherd, or at least seem
to "act" like UMN gopherd.  (You can usually tell partially by the
selector, UMN tends to double up the "type" field of the selector for
its own benefit)  The problem is that UMN gopherd sometimes does
things that might be a bit unexpected.  

For example, when I was writing this client, it would display in the
window what selectors a menu had available, and let's say one of them
was 'foo.txt.gz'.  Now for the purposes of the application, that's a
gzipped file, but one problem is that some UMN gopherd users have
translators set up so you don't get the gzipped file - it filters it
through gunzip before sending you the contents.  The result is that if
you list the size of this file, you will be wrong - (leading to a bug
in my program when downloading large files, you can get to 145%
complete, since you're downloading more data than was reported in the
filesize).  Also, if you say, "Oh, that's a .gz file, maybe I'll zcat
it and do something with it" you might be suprised.

So from the filesystem level, even with gopher+ I'm not sure there's a
way to reliably tell the size of the file.  (A while back, I patched
UMN gopherd to try to lie about file length as little as possible, in
other words if gopherd knew it was going to use a translator, it would
not specify the number of bytes it was going to send) but there are
many old gopher servers out there and other servers, so file size
isn't reliable.  Neither is file extension as a method of knowing what
type of data you're getting.

Just some things to look out for.  :)
-- 
David Allen
http://opop.nols.com/
----------------------------------------
The turtle lives 'twixt plated decks
Which practically conceal its sex.
I think it clever of the turtle
In such a fix to be so fertile.
                -- Ogden Nash