Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Feb 2002 16:14:26 -0500 (EST) Return-Path: <wzk@happy-ent.de> Delivered-To: gopher@complete.org Received: from um1b.pce.de (um1b.pce.de [213.185.64.7]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id F3C2E3B830 for <gopher@complete.org>; Wed, 20 Feb 2002 16:14:23 -0500 (EST) Received: from win98 (ppp-huerth-07.pce.de [213.185.65.135]) by um1b.pce.de (8.9.3/8.9.3) with SMTP id WAA01995 for <gopher@complete.org>; Wed, 20 Feb 2002 22:14:19 +0100 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 X-Mailer: Opera 5.11 build 904 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 479 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: wzk@happy-ent.de Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

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