Received: with LISTAR (v1.0.0; list gopher); Sat, 12 Jan 2002 13:11:53 -0500 (EST) Return-Path: Delivered-To: gopher@complete.org Received: from ns2.tudelft.nl (ns2.tudelft.nl [130.161.180.65]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 29A0D3B8E8 for ; Sat, 12 Jan 2002 13:11:53 -0500 (EST) Received: from listserv.tudelft.nl (listserv.tudelft.nl [130.161.180.33]) by mailhost1.tudelft.nl (PMDF V6.0-025 #37171) with ESMTP id <0GPU003527VREV@mailhost1.tudelft.nl> for gopher@complete.org; Sat, 12 Jan 2002 19:11:52 +0100 (MET) Received: from mailhost.tudelft.nl (kvz346.kvz.tudelft.nl [130.161.68.146]) by listserv.tudelft.nl (8.10.2+Sun/8.10.2) with SMTP id g0CIBof05897 for ; Sat, 12 Jan 2002 19:11:51 +0100 (MET) Date: Sat, 12 Jan 2002 19:15:46 +0100 From: Stefan Rieken Subject: [gopher] Re: GopherFS implementation questions In-reply-to: <"from jgoerzen"@complete.org> To: gopher@complete.org Message-id: <20020112191546.A3643@Pflipp> MIME-version: 1.0 X-Mailer: Balsa 1.0.pre5 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit References: <87y9j3fqy7.fsf@complete.org> X-archive-position: 323 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: StefanRieken@SoftHome.net Precedence: bulk Reply-to: gopher@complete.org List-help: List-unsubscribe: List-software: Listar version 1.0.0 X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher 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."