Message-Id: <200202202114.WAA01995@um1b.pce.de>
Date: Wed, 20 Feb 2002 22:19:46 +0100
To: gopher@complete.org
From: Wolfgang Zekoll <wzk@happy-ent.de>
Subject: [gopher] Re: Gopher wishlist
Organization: 0
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


Hello,

I was away from my computer for some weeks so my reply comes a little bit
late but perhaps not too late.

In my opinion the key to gopher extensions is already there, it's in the
gopher+ blocks.  The +blocks have a defined format but they are open to
whatever content we like to put in there.  Metadata was mentioned in this
threat and this fits perfectly into the item's +blocks, as long as server
and client programmers and agree on how the metadata is provided, e.g. the
name of the information block (+META:?) and it's format (MIME-header?).

The item's content-type could also be found by inspecting the item's
+blocks before fetching the item itself.

Someone here asked "What makes gopher gopher?", or in other words "What is
the difference to HTTP?"  My personal answer to this question is that in
gopher divides content from navigation.  I see gopher types in two main
categories: one are menus (and querys) and the other are the content elements,
plain text, graphics, arbitrary binary types.

The difference to HTTP/HTML is that not only the users recognises navigational
elements as navigation.  Also the browser knows that it displays a menu and
that this is navigational content.  By the way, gopher menu items doesn't have
to be rendered as a line of text.  Gopher menus can be rendered as whatever
the client's programmer wants it as long as the server provides the required
information.

This could be used by a clever gopher+ client.  gopher+ can be used to fetch
the recursive directory tree from a server in one request.  Since the client
knows that this is navigational information the client could offer it's user
a method to search locally through the gopher+ +blocks tree from different
servers (based on the user's history or configured preferences).  Try this
with HTTP/HTML.

But the important thing to all possible extensions is "client software".  We
are simply in need of usable client software.  The only gopher+ client around
is (as far as I know) the UMN client.  I don't like it very much because it
doesn't make real use from gopher+.

Regards

Wolfgang Zekoll