Received: with LISTAR (v1.0.0; list gopher); Mon, 11 Feb 2002 16:13:12 -0500 (EST) Return-Path: <x@mothra.dyndns.org> Delivered-To: gopher@complete.org Received: from mothra.dyndns.org (pool-141-152-12-174.rich.east.verizon.net [141.152.12.174]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 8C7E73B8AB for <gopher@complete.org>; Mon, 11 Feb 2002 16:13:10 -0500 (EST) Received: from x by mothra.dyndns.org with local (Exim 3.34 #1 (Debian)) id 16aNid-0007WD-00 for <gopher@complete.org>; Mon, 11 Feb 2002 16:10:35 -0500 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 X-archive-position: 424 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: mda@idatar.com Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:listar@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Listar version 1.0.0 X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

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.