To: gopher@complete.org
Subject: [gopher] GopherFS implementation questions
From: John Goerzen <jgoerzen@complete.org>
Date: 12 Jan 2002 11:56:48 -0500
Message-ID: <87y9j3fqy7.fsf@complete.org>
Lines: 66
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
MIME-Version: 1.0
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


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.

First thing -- do we present filenames or "menu names" in the
filesystem?  I was leaning towards filenames at first.  They're
especially better for people NOT using UMN gopherd or using UMN
gopherd >= 3.0 because extensions like .tar.gz, .txt, etc. will be
preserved.  However, this is quite different from how one normally
browses Gopherspace and might leave the user confused.

On the other hand, if long names are used, command-line navigation
could be tricky (escaping all those spaces -- ick) and there's the
issue of what to do with embedded slashes.

In both cases, we have a problem of what to do about duplicate
entries.  For instance, we might have a gopher directory that looks
like this (assuming UMN server specs for a sec):

Path=./readme.txt
Name=README for WhizBang v1.0/i386
Host=+
Port=+

Path=/archivers/zip/readme.txt
Name=README for ZIP v1.5/i386
Host=+
Port=+

Path=/archives/unzip/readme.txt
Name=README for UnZIP v1.5/i386
Host=gopher.std.com
Port=70

Presenting this as a directory, there would be three readme.txt files
in it.  However, it's also possible to have several menu entries with
the same name so the problem exists there too.

Then there's the problem of presenting a tree.  This is mostly a
problem because of UMN gopherd.  Consider:

/gopher/quux.org:70/1/Software/Gopher/

However, a file in there might be:

/gopher/quux.org:70/0/Software/Gopher/readme.txt

The gopherd adds the "1" or "0".  (We don't need it for the FS since
stat() can return the info needed.)  But, you can't browse the
hierarchy under /0/ because that tells gopherd that you want a text
file and it won't serve up directories that way.

So, there are two options:

1. Use a bunch of symlinks
2. Remember in the FS the actual path of each object in Gopherspace
   and resolve that at runtime.

Brainstorms, thoughts, etc. are welcome.

-- John