Received: with LISTAR (v1.0.0; list gopher); Mon, 11 Feb 2002 17:09:08 -0500 (EST) Return-Path: <sugaku@sympatico.ca> Delivered-To: gopher@complete.org Received: from tomts19-srv.bellnexxia.net (tomts19.bellnexxia.net [209.226.175.73]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 14A143B83E for <gopher@complete.org>; Mon, 11 Feb 2002 17:09:07 -0500 (EST) Received: from sympatico.ca ([64.228.192.69]) by tomts19-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020211220906.EWUG22905.tomts19-srv.bellnexxia.net@sympatico.ca> for <gopher@complete.org>; Mon, 11 Feb 2002 17:09:06 -0500 Message-ID: <3C6840C8.DE3E7436@sympatico.ca> Date: Mon, 11 Feb 2002 17:08:08 -0500 From: Ralph Furmaniak <sugaku@sympatico.ca> X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: gopher@complete.org Subject: [gopher] Re: Gopher wishlist References: <3C682904.BF4BE07D@sympatico.ca> <20020211161035.A28611@mothra.dyndns.org> <3C6838E2.C2902027@sympatico.ca> <20020211165212.A28993@mothra.dyndns.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 429 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: sugaku@sympatico.ca Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:listar@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Listar version 1.0.0 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

> 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.

One of the things we should do is finally make a good gopher+ rfc/spec.

> 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.

True, everything can be done in the current framework. We can just keep this plan B open.

> 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. :)

This could be resolved by having txt.gz and txt listed as seperate views (for the lucky gopher+ folk). Does anyone feel that the views line should contain some sort of selector? Also, umn gopher client requires the language to be included, even though the protocol doesn't.