[gopher] Re: Gopher wishlist

[Ralph Furmaniak <sugaku@sympatico.ca>]

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