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

[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: David Allen <mda@xxxxxxxxxx>
Date: Mon, 11 Feb 2002 16:52:12 -0500
Reply-to: gopher@xxxxxxxxxxxx

On Mon, Feb 11, 2002 at 04:34:26PM -0500, Ralph Furmaniak wrote:
> 
> I do not quite agree about backwards compatability.  Gopher+ was
> designed to be 
> backwards compatible, but if you look you'll see that the client request 
> specifically signals whether it be gopher0 or gopher+, and the
> server sends back 
> different data depending.  umn gopher client (AFAIK) always sends a
> '$' request 
> to the server, and the umn server then sends back something that
> would cause a gopher0 client to choke and die.

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.  

For example, I wrote a client that always sends gopher0 requests, and
only sends gopher+ requests when it can tell from how the server
responds that the server supports gopher+.  In other words, I'm trying
to be "polite" by not spewing gopher+ unless I have evidence the other
end supports it.  One thing I would like to see in any future gopher
spec is a solid statement that if you speak protocol X, you should
always speak it, or sometimes speak it depending on what the server
says.  Just nail it down.

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.

> 
> What could be put into the header/metadata?  I don't know.  I'm sure
> many people 
> would be against implementing cookies <g>.  There could be a title included
> (might be some benefits, might not.  depends on the client), and maybe a
> content-type.  I guess there isn't much use; gopher already has sufficient
> capabilities.

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

-- 
David Allen
http://opop.nols.com/
----------------------------------------
"If you go on with this nuclear arms race, all you are going to do is 
make the rubble bounce" 
- Winston Churchill 


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