Complete.Org: Mailing Lists: Archives: gopher: February 2002:
[gopher] Re: Gopher wishlist

[gopher] Re: Gopher wishlist

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: Gopher wishlist
From: Ralph Furmaniak <sugaku@xxxxxxxxxxxx>
Date: Mon, 11 Feb 2002 17:08:08 -0500
Reply-to: gopher@xxxxxxxxxxxx

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

[Prev in Thread] Current Thread [Next in Thread]