Received: with ECARTIS (v1.0.0; list gopher); Tue, 16 Apr 2002 01:33:56 -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 41E0F3B891 for <gopher@complete.org>; Tue, 16 Apr 2002 01:33:55 -0500 (EST) Received: from win98.happy-ent.de (ppp-huerth-61.pce.de [213.185.65.189]) by um1b.pce.de (8.9.3/8.9.3) with ESMTP id IAA20929 for <gopher@complete.org>; Tue, 16 Apr 2002 08:33:53 +0200 Message-Id: <5.1.0.14.1.20020416082341.009ef110@um1b.pce.de> X-Sender: qe-wzk@um1b.pce.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Apr 2002 08:40:16 +0200 To: gopher@complete.org From: Wolfgang Zekoll <wzk@happy-ent.de> Subject: [gopher] Re: The handling of +ABSTRACT In-Reply-To: <36784F3C-5086-11D6-B04F-0003930BF072@complete.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 594 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

>I will see if an extra indicator can be presented for UMN gopher so that >clients can see the availability of the abstract information. Perhaps >gopherc can get a similar on-screen indicator?

Well, +ABSTRACTs are not the only things that might be hidden from the screen. I think of a +LINKS block where each item can have a gopher0 menu of related files/items on it's own (without a complete menu). Think of "related" or "see also" links. I have also some other ideas in my mind.

Then there is the more general question: How can the server inform the user that there are invisible items waiting for the user? My personal favourite if the following: The client inspects the gopher+ block of the directory and if it find a +README entry it fetches automatically also this +README, displays it and leaving the readme text brings the user into the gopher directory. While I think this idea is nice on one hand it seems to break compatibility to gopher0 clients, how do they notice the readme if it's hidden? Repeating the readme (together with perhaps the abstracts) could be boring to the gopher+ clients (why do I see the same file again?).

This could be solved with different directory views, the standard including all for gopher0 and minimal for gopher+ with hidden ABSTRACTs and README etc. But I also think of dividing the gopher+ directory into several parts or views (where `view' is not related to the +VIEWS). This works as follows:

+INFO: 9binary.zipF9/binary.zip +ADMIN: ... view: data +ABSTRACT: 0binary.zip's AbstractF0/binary.txt +INFO: 0binary.zip's AbstractF0/binary.txt +ADMIN: view: abstract ... more items appear here ... +INFO: 0About this directoryF0/readme.txt +ADMIN: ... view: readme +ABSTRACT: The directory's `i' items go here.

Then the gopher client can offer the user which view to show to the user, either data, abstract, readme or gopher0 being compatible to normal gopher0 clients.

Any comments?

Regards

Wolfgang Zekoll