[gopher] Re: GopherFS implementation questions

[Stefan Rieken <StefanRieken@xxxxxxxxxxxx>]

Hi,

I'm about to release a new version of gnopher, a Gopher client for Gnome.
This new release integrates with gnome-vfs and Nautilus. In fact, I've
spoilt the surprise now, but please still look forward to it. I expect to
have screenshots on Sourceforge in the next few days, and a release
somewhere after that.

As you'll understand, writing a Gnome VFS module is quite the same as
writing a Linux VFS module, only the integration is done at another system
level. I've had a lot of trouble translating Gopher concepts to filesystem
concepts. You'll most likely be having the same problems, and maybe less
space to solve them than I had (I solved them by writing a Nautilus view in
addition to the VFS module).

So I'll explain my experiences here, and I guess there's a lot to learn
from them :-/

The Gnome VFS tries to represent all kinds of protocols in a filesystem
fashion that is very close to the UNIX fs fashion. When implementing
anything like HTTP or Gopher on top of that, one should be able to ignore
most of this (e.g. special files, file permissions etc.), or lie a little
bit (e.g. making up file permissions). Of course, integrating HTTP with the
Gnome VFS is easily done, because that's what it was written for in the
first place.

Gopher has two problems that aren't easily overcome by means of Gnome VFS
resources. One large problem is the fact that the "standard" Gopher URL's
(e.g. as they can be used in browsers, like
"gopher://gopher.quux.org/1/Software/Games/CoCo";) aren't in any way
structured. One _cannot_ expect that "/" is the directory delimiter, and as
a result you can't tell for sure that "CoCo" the filename.

This has all kinds of annoying side effects. For instance, if you want to
look up the file type of a file, you're tempted to go to its parent
directory to check it out. But *there's no such things as a parent
directory*. And if you have a Gopher "directory" listing, you're tempted to
assert that the files listed there reside in that folder. Instead, they're
all links to (as far as the protocol is concerned) random new Gopher
locations.

So when I would represent a Gopher "directory" to the Gnome VFS as being a
directory, it assumes that the files listed are *inside* that directory.
Problem. Representing the files as symlins doesn't resolve this, because
the symlinks are being resolved transparently (e.g. when foo -> bar and
bar/fred.txt, clicking on foo will just bring you in the directory of "foo"
with the contents "fred.txt", instead of non-transparently redirecting you
to "bar" first).

Now this could be resolved by adding some extra information to a file
listing. I first did just that, I stored the correct location in the
"symlink location" field. This only to find out that the VFS only supplies
you with the (incorrect :-() URL when it requests a new file to be loaded.
Gone is the "symlink location" information, and there's no way to look it
up again, because that's listed in the "parent directory" of the requested
file, which, as said, can't be found out from the URL...

So I had to write a Nautilus view in addition to the VFS component to
overcome these problems. (Besides that, I had some problems with mime type
detection, but that's not really important to you.)

All in all, I'm not quite sure if you _can_ represent Gopher in a FS
structure. It will take some really ugly translation-step hack to say the
least. Or you should of course be able to use Windows-like symlinking,
which work non-transparently, just as you'd need it.

And mind you, I haven't even fought the battle of Gopher+ yet... (I see
material for a sequel here :-/)

Good luck,

Stefan Rieken
-- 
"'Abnormal Psychology'. Are you a doctor, mr. Murdock?"
"Uh, no ma'am, I'm insane."