[gopher] Re: Gopher wishlist
> 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.