Message-ID: <3C6840C8.DE3E7436@sympatico.ca>
Date: Mon, 11 Feb 2002 17:08:08 -0500
From: Ralph Furmaniak <sugaku@sympatico.ca>
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
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


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