Received: with LISTAR (v1.0.0; list gopher); Mon, 11 Feb 2002 16:54:41 -0500 (EST) Return-Path: Delivered-To: gopher@complete.org Received: from mothra.dyndns.org (pool-141-152-12-174.rich.east.verizon.net [141.152.12.174]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id EEF143B83E for ; Mon, 11 Feb 2002 16:54:40 -0500 (EST) Received: from x by mothra.dyndns.org with local (Exim 3.34 #1 (Debian)) id 16aOMu-0007Xk-00 for ; Mon, 11 Feb 2002 16:52:12 -0500 Date: Mon, 11 Feb 2002 16:52:12 -0500 From: David Allen To: gopher@complete.org Subject: [gopher] Re: Gopher wishlist Message-ID: <20020211165212.A28993@mothra.dyndns.org> References: <3C682904.BF4BE07D@sympatico.ca> <20020211161035.A28611@mothra.dyndns.org> <3C6838E2.C2902027@sympatico.ca> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C6838E2.C2902027@sympatico.ca>; from sugaku@sympatico.ca on Mon, Feb 11, 2002 at 04:34:26PM -0500 Content-Transfer-Encoding: 8bit X-archive-position: 428 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: mda@idatar.com Precedence: bulk Reply-to: gopher@complete.org List-help: List-unsubscribe: List-software: Listar version 1.0.0 X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher On Mon, Feb 11, 2002 at 04:34:26PM -0500, Ralph Furmaniak wrote: > > I do not quite agree about backwards compatability. Gopher+ was > designed to be > backwards compatible, but if you look you'll see that the client request > specifically signals whether it be gopher0 or gopher+, and the > server sends back > different data depending. umn gopher client (AFAIK) always sends a > '$' request > to the server, and the umn server then sends back something that > would cause a gopher0 client to choke and die. Unfortunately, one of the things that isn't specified by the Gopher+ spec as far as I know is whether or not clients should communicate with gopher+ if they're capable of it. For example, I wrote a client that always sends gopher0 requests, and only sends gopher+ requests when it can tell from how the server responds that the server supports gopher+. In other words, I'm trying to be "polite" by not spewing gopher+ unless I have evidence the other end supports it. One thing I would like to see in any future gopher spec is a solid statement that if you speak protocol X, you should always speak it, or sometimes speak it depending on what the server says. Just nail it down. As for backwards compatibility, I guess some would say that gopher is small now relative to other things, and that if we're going to make changes they should be now. Others think that making changes and breaking backwards compatibility threatens to alienate the few people who do still use gopher. I tend to be in the latter camp, but I'm not immune to good arguments, I guess I just haven't seen a feature yet that was sufficiently needed and sufficiently difficult to implement without breaking backwards compatibility. > > What could be put into the header/metadata? I don't know. I'm sure > many people > would be against implementing cookies . There could be a title included > (might be some benefits, might not. depends on the client), and maybe a > content-type. I guess there isn't much use; gopher already has sufficient > capabilities. Content-type might be nice. Although I like the translators in UMN gopherd, it still kinda bugs me when I request, say, FOOBAR.txt.gz from some server, where it's 2142 bytes, and I end up getting text, (not gzipped text) back, and 44014 bytes. :) -- David Allen http://opop.nols.com/ ---------------------------------------- "If you go on with this nuclear arms race, all you are going to do is make the rubble bounce" - Winston Churchill