Received: with LISTAR (v1.0.0; list gopher); Fri, 05 Jan 2001 12:43:43 -0600 (CST) Return-Path: Delivered-To: gopher@complete.org Received: from gtei1.bellatlantic.net (gtei1.bellatlantic.net [199.45.40.145]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 444963B812 for ; Fri, 5 Jan 2001 12:43:42 -0600 (CST) Received: from mothra (adsl-141-152-12-101.bellatlantic.net [141.152.12.101]) by gtei1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id NAA00050 for ; Fri, 5 Jan 2001 13:40:57 -0500 (EST) Received: from x by mothra with local (Exim 3.20 #1 (Debian)) id 14Ebml-000486-00 for ; Fri, 05 Jan 2001 13:40:19 -0500 Date: Fri, 5 Jan 2001 13:40:19 -0500 From: David Allen To: gopher@complete.org Subject: [gopher] Re: Gopher for GNOME... Message-ID: <20010105134019.D15761@mothra> References: <20010104000041.A17797@mothra> <87elyi1vaq.fsf@complete.org> <20010104233455.A11495@mothra> <20010105163148.7BE357C22@hirogen.kabelfoon.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20010105163148.7BE357C22@hirogen.kabelfoon.nl>; from StefanRieken@SoftHome.net on Fri, Jan 05, 2001 at 05:31:47PM +0100 Content-Transfer-Encoding: 8bit X-archive-position: 33 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: s2mdalle@titan.vcu.edu Precedence: bulk Reply-to: gopher@complete.org X-list: gopher On Fri, Jan 05, 2001 at 05:31:47PM +0100, Stefan Rieken wrote: > In Nautilus, a file is just a metaphor. It can be a record of MP3's even > with a cool cover, it can be one of the Nautilus services, it can be a > representation of your hardware. So why can't it be a Veronica search > engine? People will get used to doing about everything with their shell. > Especially viewing stuff. Nautilus already supports FTP and HTTP as > viewing protocols, and HTML, various image formats, and the stuff I just > described as viewers (more, like PostScript etc., to come). Well it can be a veronica search engine, and it can represent all the things that gopher and gopher+ can do. What I was trying to say is that if gopher develops more into the direction of the web, absolutely you can still use this metaphor to display everything, it's just that if you use the file manager way of doing things, it seems likely that in order to shoehorn in all of the different types of content and views and so on, you're going to end up trying to implement a browser. Putting metadata issues of gopher+ aside for a moment (I agree that they are very important) the only core difference to the user between http and gopher is that all of the directory listings are different from site to site, server to server with http, and with gopher, it's all the same. Yes there are all sorts of things that the web does that gopher does'nt, but that's more an issue of what has been traditionally done, and not reflective of what *can* be done with gopher. But if they're essentially the same, and a file manager view is good overall for gopher, then why haven't we seen a web browser implemented in that type of way? I think because that type of view is *excellent* for a subset of gopher, but falls short for the whole picture. On the other hand, doing things in a browser sort of fashion (the way gopher or netscape does it) is klunky on the simple stuff. (Like the stuff file managers are good at) > Also, Nautilus supports multiple views for one file. Gopher+ also does > this, only in an even more extended way (e.g. a text and a PostScript > version, different languages). Well that is a cool thing about gopher+. I haven't come across any sites that use alternative views much - does anybody know of any? > Whether you like the Nautilus approach to the graphical shell or not, > you'll have to agree that Gopher+ _does_ seem to be sent from heaven for > this filemanager. Imagine how easy it would be for e.g. schools to set > up a Gopher+ service, that is to students just an extention of their > file system. Currently, in _my_ school (which sux :-), you'll have to > use shared disks half of the time (Samba/ NFS), and the other half of > the time you're using the Intranet. That is not a consistent approach, > and sometimes I'd even call it ugly. I'm not overly familiar with Nautilus, but yes, gopher+ does seem to be sent from heaven. It's not so much the protocols that I'm thinking of, it's more things like dynamic programs, and things like Veronica searching that I associate much more with a browser than with a file manager. And again, certainly you can put that functionality in a file manager. It just seems to me that at that point you might be moving towards a browser in development, and if that's the case, why not just use a browser? > If this were to be implemented through Gopher+ and Nautilus, I would be > drooling. Looking for a teachers mail address? Open a shell, "School > services" -> "Address information" (enter a name) -> taddaa! > > Sorry, but I am _really_ enthousiastic about this. It's the future to > me... Sorry? Why? That's why we do this - because it's fun. > So I am currently trying to convince the Nautilus guys to keep a > possibility open to implement this sort of stuff, before API freeze. No > answer yet (mailed yesterday late). Hope I have enough spare time for > this little revolution ;-) Well good luck. :) We may not agree on everything, but I'm not going to turn down new software in any form. > > In short, some people like to talk about gopher's ability to provide > > all of the services that the web does. But the way the web is put > > together and used, the file manager type of interface wouldn't be all > > that great for it. If gopher evolves in that direction, I think the > > file manager type way of looking at things might become less useful. > > The Web can't provide extensive metadata and file view support, which > Gopher+ can. Nautilus is, just like Windows Explorer and Konqueror too, > trying to make the Web part of the filesystem. I'd rather have them to > do it well with the help of Gopher+, than to make a sorryful layer atop > of HTTP, which just sucks: HTTP wasn't meant for a hybrid approach of > directory listings and file views, which is what they all want to > implement. No, I didn't mean to layer anything on top of HTTP. What I mean is that using gopher/gopher+, you can pretty much mimic anything that is done on the web. Hypothetically, if within the next year gopher were to explode in popularity, there would be a lot of people trying to do webbish things with gopher. (That's what they're used to) And they'd succeed, using gopher. But the type of material that's on the web in my opinion doesn't lend itself very well in many cases to being displayed in a file manager type layout. > I hope I can keep up this enthousiasm long enough though, I usually have > some problem with it. Good luck again. -- David Allen http://opop.nols.com/ ---------------------------------------- 99 little bugs in the code, 99 bugs in the code, fix one bug, compile it again... 101 little bugs in the code....