Date: Mon, 11 Feb 2002 16:10:35 -0500
From: David Allen <mda@idatar.com>
To: gopher@complete.org
Subject: [gopher] Re: Gopher wishlist
Message-ID: <20020211161035.A28611@mothra.dyndns.org>
References: <3C682904.BF4BE07D@sympatico.ca>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3C682904.BF4BE07D@sympatico.ca>;
 from sugaku@sympatico.ca on Mon, Feb 11, 2002 at 03:26:44PM -0500
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Mon, Feb 11, 2002 at 03:26:44PM -0500, Ralph Furmaniak wrote:
> 
> Do we really have to stick to the gopher+ specs?  There are some things
> that could be done differently, or new features added to the protocol.
> We have practically all the maintainers of maintained gopher progs in
> this group so why can't we tinker with the protocol a bit?  If people
> have some ideas of things they would like to see in gopher, we can try
> to put these together.

I like some of your ideas, but one thing I did want to say is that
usually I'm immediately pretty wary of "new feature requests" to the
gopher protocol, mostly because I don't want anybody to try to
reimplement HTTP poorly in terms of gopher.  Some of the feature
requests I've seen in the past were aimed at allowing gopher to have
features similar to that of HTTP.  One of the draws of gopher is that
it's clean and simple, and if you want something that can do things
like HTTP can do, well, uh, there's HTTP.  :)

> For example we could allow actual linking to http servers, just like you
> can link to telnet, ftp, and other resources.

Agreed there - did you have in mind just like a new type character?

> Also, we could change around the ASK structure, some people were
> talking/complaining about it earlier.

Think I missed this discussion - what was the main gripe?

> It would be nice if we could put in some redundant/backup/mirror server
> capabilities, so the same resource could come from multiple servers.
> Slashdot protection!

Not a bad idea, but let me ask you this - don't you think that most
new features in a protocol should be driven primarily by need rather
than the "that's pretty cool" method of protocol development?  The
reason I ask is because I don't know of any gopher servers that are
being slashdotted.  I wish more servers had that problem.  :)

> We could also put some information into headers, similarly to what http
> does.  This would also be a good place to put in the server information
> (abstracts?).  You could also request a specific chunk of a file, so
> that you can resume failed downloads.

Ah, HTTP rears its head.  :)

Basically, these "headers" act as something like metadata, no?
Generally, when you ask for data from the server, you're asking for a
document or some other chunk of information, whatever it happens to
be.  Already, one small piece of "metadata" is supported - the length
of the data being sent, and this is optional. 

Do you have any specific ideas for what other metadata would be
appropriate?  As for abstracts about particular documents, this is
more or less already supported in Gopher+ by requesting info about a
particular document.

Here's my big question though - can you suggest a way to implement
this metadata in a way that doesn't break backwards compatibility?
Of the people who are still using gopher, maybe not all of them are on
this list and following gopher software development - you can be sure
that many are using old versions of UMN's gopher client, lynx, and so
on.  Can we add these features without breaking their clients?  

Don't get me wrong, I like the idea of adding features to gopher, but
I think we should keep the following in mind:

- Backwards compatibility is important
- Focus on what gopher is good at when improving
- Don't copy other protocols (like HTTP) keep gopher in the domain
  it's good at
- Focus on new features that will address existing problems rather
  than potential problems or "wish list" items.

-- 
David Allen
http://opop.nols.com/
----------------------------------------
The use of COBOL cripples the mind; its teaching should therefore be regarded 
as a criminal offense."    
	- E W Dijkstra.