Date: Mon, 15 Apr 2002 11:46:27 -0500
Subject: [gopher] Views
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: 
 <20020415154543.HXHJ3414.tomts6-srv.bellnexxia.net@[209.226.175.22]>
Message-Id: <54887CA6-5090-11D6-B04F-0003930BF072@complete.org>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


Ralph,

Sorry, I lost the location -- where can I find info or downloads for 
your fork?  I prefer info so I can reimplement features I like without 
risking violating bucktooth's license (even though that derivitive 
clause is probably too broad to be enforcable)

On Monday, April 15, 2002, at 10:45  AM, Ralph Furmaniak wrote:

> Anything extra in the cap or link files are treated as gopher+ 
> attributes currently.

So you're saying that your buck branch handles UMN .Links/.cap files?

> I was always wondering how gopherd allows users to set up mutiple 
> views.  I

Poorly. :-)

I believe that I even took that code out of UMN gopherd awhile back 
because it didn't work well.

Basically, UMN gopherd used viewext to determine what MIME type and 
gopher0 type a given item was.  If, after stripping off an extension, 
multiple files existed in the same directory with the same base 
filename, they would be presented as alternate views for each other.  
However, this turned out to not work well in practice because so many 
times you'd have a situation where it would match files in this way when 
they should NOT be views of each other.  Worse, for gopher0 clients, 
there was zero indication to the client that any other views existed -- 
that is, only one view of the file would be visible.

So I yanked the code :-)  UMN gopherd 3.x does not support multiple 
views at this time.

> just set it up so that you put the files into `filename.dir` and put 
> `filename` in the gophermap/link/cap/whatever.  I think this is the 
> easiest way for publishers.  gopher0 and http requests for `filename` 
> are given a menu.

I'm not quite following, can you clarify a bit (even with an example)?

> I would support the use of abstracts, it should make a cleaner display, 
> especially for filesystem- or tree- based clients.  Also, in the http 
> version these could be hidden until the person passes the mouse over 
> the item.

Indeed.  Already thought of that but have no idea how to do it :-)

> Should the info come before or after the item?  Should there be a 
> separate

I'd say leave that up to the server or the admin.  I think it looks best 
after.  UMN gopherd's http server shows them after, FYI.

> attribute for each of these?

Not quite sure what you mean here.

> The menu itself can have an abstract, which is what is displayed as the 
> header.

Ah, I like that thought a lot.