Received: with LISTAR (v1.0.0; list gopher); Sun, 14 Jan 2001 23:47:35 -0600 (CST) Return-Path: Delivered-To: gopher@complete.org Received: from gtei1.bellatlantic.net (gtei1.bellatlantic.net [199.45.40.145]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 0C11C3B912 for ; Sun, 14 Jan 2001 23:47:35 -0600 (CST) Received: from mothra (adsl-141-152-12-101.bellatlantic.net [141.152.12.101]) by gtei1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id AAA14149 for ; Mon, 15 Jan 2001 00:43:46 -0500 (EST) Received: from x by mothra with local (Exim 3.20 #1 (Debian)) id 14I2Nn-0007a5-00 for ; Mon, 15 Jan 2001 00:40:43 -0500 Date: Mon, 15 Jan 2001 00:40:43 -0500 From: David Allen To: gopher@complete.org Subject: [gopher] Re: Gopher "robots.txt" Message-ID: <20010115004043.A29080@mothra> References: <20010114211300.A885@success-info.com> <200101150532.VAA09174@stockholm.ptloma.edu> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <200101150532.VAA09174@stockholm.ptloma.edu>; from spectre@stockholm.ptloma.edu on Sun, Jan 14, 2001 at 09:32:45PM -0800 Content-Transfer-Encoding: 8bit X-archive-position: 100 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: s2mdalle@titan.vcu.edu Precedence: bulk Reply-to: gopher@complete.org X-list: gopher On Sun, Jan 14, 2001 at 09:32:45PM -0800, Cameron Kaiser wrote: > > It wouldn't be that much of a performance hit. Rather than fetching the > > directory with a normal gopher request, then fetching the attributes for > > each entry of the directory, the robot could make a request something > > like this: > > > > 1/directoryF$+VIEWS+ABSTRACT+ROBOTS > > This is a excellent idea, but I don't think we want to require all robots or > robot-like things to be gopher+ compliant. It would be nice, but I don't > think it should be mandatory. Well if you're going to staple something new onto gopher, it makes sense to do it in gopher+, rathern than modifiying the original gopher with additions to it rather than gopher+, since after all gopher+ was just a set of modifications to gopher. :) > Also, this doesn't solve the problem adequately for those *servers* which are > not gopher+ compliant, or certain subsets of indexed search servers that can't > or don't make gopher+ compliant responses (I can think of several immediately). Hm. Well, I can agree with this, but at the same time, what is to become of gopher+? You can either merge it with the original gopher and say "this is what gopher is, and we'll write software accordingly", or you can throw out gopher+ and stick only with gopher, but having gopher+ sitting around as something that might be supported and might not be seems like a pain. Gopher+ has some decent abilities, and I don't see why you shouldn't use them in this situation. So maybe we should be asking if gopher+ is something that should continue to be sometimes-supported, or if it should be taken in or thrown out. -- David Allen http://opop.nols.com/ ---------------------------------------- Official Project Stages: (1) Uncritical Acceptance (2) Wild Enthusiasm (3) Dejected Disillusionment (4) Total Confusion (5) Search for the Guilty (6) Punishment of the Innocent (7) Promotion of the Non-participants