[gopher] Re: Gopherness

[Cameron Kaiser <spectre@xxxxxxxxxxxx>]

Nice essay. I'll just intersprinkle my own particular comments:

> - Putting "up" or "previous menu" items in menus which points into your 
> personal "data island".

This is controversial to me. I do understand the ideal nature of such
a thing where a menu can be composed of multiple resources on multiple
servers and still appear as if it were a unified single menu. This is
one thing Gopher menus do better than HTML pages.

On the other hand, on summary sites or menus that take only bits and
pieces, it's hard for a user to see what else a server offering menu item
X might offer them without such navigation. Say menu Y had a link to Z, a
document about George Washington's toenails. The server offering Z might
also have a document on his fingernails, but it's harder (obviously by no
means impossible, but certainly not convenient) to find that out, and
menu Y will not give you that unless it also connects to the fingernail
document.

This was part of why I added the U-turn icon to Overbite menus, but the
interface is incomplete because it only appears on menus. In fact, I've
been weighing turning the U turn icon into a XUL overlay so that people can
do that from any document.

Probably the best middle ground for this is, indeed, to have the client
offer such "up" options.

> - Adding an Endless Array of New Item Types for Every New Thing that 
> Comes Along
> This is a www disease that has spread to gopher.  Browsers (and their 
> associated plug-ings and "readers") grow exponentially eating up storage 
> space and connectivity bandwidth.  This is because browsers are "smart" 
> clients that access essentially simple servers.  Most of the 
> intelligence is in the ever-bloating client.  Gopher is (or should be) 
> the opposite:  a smart server that contains all the intelligence and a 
> relatively simple client that only moves among menus, displays ASCII 
> text, and downloads files.

We sort of beat this to death in the item types discussion :) but I do
agree I would prefer a simple client and more work on the server side. Where
I still think item type expansion is needed is for those things where the
client might want to do more with a particular resource, or in the case of
fat clients, but I think I've already said my piece. :)

> - Creating "Wrappers" for Things that Don't Easily Fit the 
> Menu/Text/File Model
> This is just laziness oftentimes.  If something cannot be rendered to 
> menus or texts simply, it get shoved into a binary file.  MIME is a 
> wasteland of different reditions of often common things, requiring 
> seperate readers for each type.  Most PDF files are predominately text 
> with a few pictures or other such things in them.  A Gopher rendering 
> would be a menu that points to a text (that contains the PDF text) and 
> binary files (that contain pictures and the other things from the PDF 
> file), which allow a person to read the text without dealing with the 
> pictures until the person deems it necessary.  No "reader" needed until 
> you want to deal with pictures, for example. The Gopher server (as the 
> brains of the operation) should convert such binary things into common 
> formats that can be read by the gopher client itself or by a few small, 
> launched "reader" programs.  You can put up the PDF file as a possible 
> download, but don't make it something everyone has to download to figure 
> out if they need it - that is bandwidth waste.

This is a good suggestion and one to consider implementing.

> - Worrying about How Things Look on the Client Side

Coming from the Mac world, I do tend to have symptoms of 'the interface
is king' disease, but I think the limited oeuvre of Gopher menus should
keep this down to a dull roar.

I don't think, however, this should restrict people from making innovative,
slick looking clients. As long as those clients support a standard text
display as Gophers are uniformly formatted for, go for it. After all, that's
how we got GopherVR. :)

> - Clients should be Created for every Computer
> The whole point of providing information to others is to make it as 
> accessible as possible.  Having to make choices in computers based on 
> the fact that "it runs the web browser I need to use" is a sad state. 
>  If I want to view local sports scores on my old c64, that should be 
   ^^^^^^^^^^^^^^^^^^                    ^^^^^^^^^^^^^
> possible.

Um ... stay tuned to the Vintage Computer Festival this year. :)

> - Rendering Everything into Either a Menu, an ASCII Text, or a 
> Downloadable File
[...]
> - Rendering Everything Else to a Handful of Established Types.
[...]
> -The Server Does All the Work

I think this is an extension of your PDF note above, which I basically
agree with. It may be a bit much to expect a gopher server to, say, transcode
or at least translocate every sort of video into a standard container, just
for an example, and we still have the problem of determining which types are
truly elemental (other than the Big Ten). In fact, even the Big Ten are
arguably NON-atomic by such a standard, since some of them can be derived
easily from other types, but they have the weight of history behind them.

> - Use Menu Titles that Stand Alone

Yes, I fully agree with this and try to do so. It also makes Veronica-2 more
efficient since titles will be more keyword-rich. Right now it uses a bucnh
of heuristics for keyword-deficient titles.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
-- LOAD"STANDARD DISCLAIMER",8,1 ----------------------------------------------