From: Ralph Furmaniak <sugaku@sympatico.ca>
To: gopher@complete.org
Subject: [gopher] Re: The road ahead
Date: Wed, 3 Apr 2002 13:42:32 EST
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: 
 <20020403184233.CBIY29105.tomts6-srv.bellnexxia.net@[209.226.175.18]>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


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

How about this: info tags are used sporadically and are replaced by the Abstract attribute.  All you are usually doing anyways is having a header (maybe a footer) and brief information about each item.  A client would display the items and display the information automatically or when needed (mouseover?).  If need be, these can be flattened for older clients.

I think we have to decide what is the best way to serve stuff.  Both the umn method and the gophermap method have their advantages, but also their problems.  One possibility is that if you put a tab and a filename (no title before) in the gophermap it loads the information from .cap and link files.  Instead of a filename you can put in a wildcard to serve the files in that directory, in another directory, or satisfying a pattern (supported in the next bucktooth, not released yet).

I also think that Links can be done away with for the most part and replaced by this system.

We could then replace .cap/foo with simply .foo (unless someone feels the former is better).