Date: Wed, 27 Mar 2002 10:55:36 -0500
Subject: [gopher] Re: The road ahead
Content-type: text/plain; charset=US-ASCII
Mime-Version: 1.0 (Apple Message framework v481)
From: John Goerzen <jgoerzen@complete.org>
To: gopher@complete.org
Content-Transfer-Encoding: 8bit
In-Reply-To: <auto-000027178978@dc-mx01.cluster1.charter.net>
Message-Id: <143EE215-419B-11D6-863F-0003930BF072@complete.org>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


Adam,

It sounds a lot like you would like to see the further fleshing-out of 
the Gopher+ protocol.

One thing I have been thinking about a lot lately is views.  I like the 
idea.  The implementation stinks.  It's complex on both the server and 
the client.  One problem with it is that for downloads, you lose the 
extension.  Big problem for almost any platform, and really annoying.  
Another is that all of a sudden there is a special case.

I might throw around some other ideas in a few minutes.

Continuing with your comments:

On Thursday, March 21, 2002, at 07:59  AM, gurno@charter.net wrote:

> + I'd like a well-defined way to send descriptive strings - i.e. the
> 'info', only defined as such.  What I'm trying to say is that using info
> seems 'kludgey' to me and I'd like a better way to say "Welcome to my
> Gopherhole!".

My personal opinion is that people (myself included) overuse the info 
strings.  A gopher directory should be a directory.  A document at the 
top of the menu like "About This Directory" is a good standard.  
Flilesystem-like browsers (vfs, konq) can deal with this better too.  
(There's not a good way to show info stuff with them.)

That said, a short info line or two pointing people to that file or 
suggesting where to start might be good.

> + A page title would be nice too - I think that this would be extremely
> helpful when bookmarking.

We could define a +TITLE tag in gopher+.  UMN gopher client 
automatically uses a title based on what the referrer called it.

> + Fully qualified URLs for links.  Rather than breaking it up across
> tabs, I would much rather see ...\tgopher://foo.foo/1:8080 - I think
> that it's easier to maintain and much more readable.

I don't see this as a protocol issue per se...  a smart server could see 
this and convert it into existing protocol quite easily.

> + And I think that the Google-ization of the Web has shown that helpful
> searching is the 'killer app'.  With that in mind, meta information
> about a page, like the Keywords and Descriptions available if the robot
> would want it.  (Clients don't really care, do they?)

Easily done with Gopher+.

> + What sort of character support is out there?  The 'net is fa-a-ar more
> international than it was back in the day - I think we need more than
> UTF-8 (or whatever)

UTF-8 / Unicode is where it's at.  We're pretty much charset-agnostic 
just so long as your charset doesn't use tab for something.  That should 
be a safe assumption.

> - Formatting information.  I'd support a simple left|center|right
>   alignment for the text strings (see above), but outside of that we'd
>   be setting ourself up for the HTML/CSS/Flash wars that are raging
>   right now.  (This includes fonts)

I don't think we should even have that.  I think of Gopher as a global 
filesystem -- you're "mounting world" when you browser gopherspace.  
People can look at it with all sorts of different interfaces just like 
you can with, eg, NFS.