[gopher] Re: Gopher for GNOME...

[Stefan Rieken <StefanRieken@xxxxxxxxxxxx>]

Cool. I just subscribed to this list and I see there's a discussion
about my proggie going on :-)

Please allow me to explain some of my reasoning behind Gnopher, that you
were discussing.


Op 04 Jan 2001 23:34:55 -0500, David Allen schreef:
> 
> On Thu, Jan 04, 2001 at 11:23:41PM -0500, John Goerzen wrote:
> > 
> > David Allen <s2mdalle@xxxxxxxxxxxxx> writes:
> > 
> > > One of the things that I noticed about it was it's directory type feel
> > > - I don't use gmc much, but it reminded me of gmc, and acted as if the
> > > gopher server was an extension of your local disk.  I took a different
> > > approach as I was writing my client, but it was interesting to see it
> > > done in this way.   


So there :-)

Honesty forces me to say that I _was_ trying to write this thing in the
shape of an icon _listing_. But GNOME only supports that kind of stuff
through a GtkList that you have to dress up yourself (or something like
that). So when I found out that the GnomeIconList was actually a
"normal" icon view, I thought, "hey actually this is good!" and kept it.

This approach to things is what my art teacher always called "laziness".
I had my own ideas about that...

> > This is an *excellent* approach, if done right.  I think this is how
> > gopher was meant to be done, especially if it is integrated into the
> > file manager.  Konqueror does it this way, and it would be an
> > excellent client if only it didn't have more bugs than Microsoft code
> > XOR'd with /dev/random :-)


Hah! I'm going to use this against the "Konqueror can do this stuff
already" trolls.

> I like the approach, but I also have some issues with it.  Treating
> gopher like an extension to a file manager program suggests the
> application of gopher in no more than a souped up directory fashion,
> when it can do so much more.  I don't see any reason why all of the
> CGI type of applications can't be run in a gopher type of way, but how
> do you represent a CGI type program on a foreign server which may take
> N arbitrary input fields as just another file on your disk?  I think
> the idea goes a very long way when dealing with things like Project
> Gutenberg archives, software archives, and especially with things like
> how UMN gopherd directory-izes mbox files.  But the more dynamic
> content, veronica searches, and other such stuff doesn't really seem
> appropriate to me within a file manager type setting.


Mind you, that is just what I want. I just sent an email to the Nautilus
development list. I feel like Gopher (especially Gopher+) is just the
protocol Nautilus is needing.

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

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

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.

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

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 ;-)

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

I hope I can keep up this enthousiasm long enough though, I usually have
some problem with it.

Greets,

Stefan

-- 
The difference between Murphy- and RFC 1123-SHOULDs:
RFC 1123-SHOULD: You SHOULD implement this part of the protocol...
Murphy-SHOULD  : ...and then it SHOULD work as expected.