Complete.Org: Mailing Lists: Archives: gopher: January 2001:
[gopher] Re: Gopher for GNOME...
Home

[gopher] Re: Gopher for GNOME...

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Gopher for GNOME...
From: David Allen <s2mdalle@xxxxxxxxxxxxx>
Date: Fri, 5 Jan 2001 13:40:19 -0500
Reply-to: gopher@xxxxxxxxxxxx

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....



[Prev in Thread] Current Thread [Next in Thread]