Received: with LISTAR (v1.0.0; list gopher); Mon, 11 Feb 2002 19:46:20 -0500 (EST) Return-Path: <rhahn@golden.net> Delivered-To: gopher@complete.org Received: from sodium.golden.net (sodium.golden.net [199.166.210.252]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id D2E9F3B835 for <gopher@complete.org>; Mon, 11 Feb 2002 19:46:19 -0500 (EST) Received: from localhost (AS53-02-69.cas-kit.golden.net [209.226.152.69]) by sodium.golden.net (8.10.1/8.10.1) with ESMTP id g1C0kGa20644 for <gopher@complete.org>; Mon, 11 Feb 2002 19:46:16 -0500 (EST) Date: Mon, 11 Feb 2002 19:42:24 -0500 Subject: [gopher] Re: Gopher wishlist Content-type: text/plain; charset=US-ASCII Mime-Version: 1.0 (Apple Message framework v480) From: Robert Hahn <rhahn@golden.net> To: gopher@complete.org Content-Transfer-Encoding: 8bit In-Reply-To: <3C682904.BF4BE07D@sympatico.ca> Message-Id: <61F7E6B1-1F51-11D6-976A-003065663F8C@golden.net> X-Mailer: Apple Mail (2.480) X-archive-position: 430 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: rhahn@golden.net 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

I read much of this thread with a lot of interest. I for one am glad that those of you who have posted are speaking with cool heads.

As I'm still waiting for some patches that would get umn's server/client to compile, I have merely contented myself to reading the specs and rfc's. And you know what? I think this is a terrific protocol for serving documents with the tiniest amount of overhead and dev time.

But while I can understand what the specs say, I have a lot of trouble trying to figure out how I could 'sell' the idea of using this to managers - heck, I have trouble trying to convince other developers that gopher is worth a look. It seems that the advantages aren't compelling enough.

And if there are compelling advantages, I'd love to hear them. And more than that: I would love to hear *why* they are compelling.

In this thread, David & Ralph agreed that we should nail the existing specs to eliminate the ambiguities that remain. I'd like to suggest that an advocacy document also be drafted to help developers and PHB's alike grok the unique and distinctive advantages of gopher. I will be happy to coordinate the drafting of this doc if I can solicit the list for ideas.

Now, let me move to another point I'd like to make: I think it's all very well and good to 'fix' or 'improve' gopher or gopher+, but I would like to suggest that we might be able to make a lot of progress if we can aim to do *something* really well.

What I would like to suggest is that maybe we should look at gopher as the perfect way to serve, say, xml/xsl docs. IIRC, the gopher spec says: Make the server smart & stateless, and the clients dumb. Ok. Why not look for ways to make a smarter client? Suppose we build a client that can request arbitrary xml documents, and automatically pull in xsl docs or allow the user to specify their own formatting rules? Let's get really clever: suppose we have a link to an xml doc that looks like this: gopher://gopher.mydomain.com/foo.xml/bar/baz/, which returns everything between the baz tags? (insert big handwaving here to cover up nitpicky details I'm sure we could iron out)

Or, put a different spin on this: what if we positioned gopher as a web services server? I'm working on a few ideas inspired from this page: http://www.xml.com/pub/a/2002/02/06/rest.html

maybe we can spearhead some initiatives based on this sort of pragmatism...

It doesn't have to be xml - but I'm figuring that there are a lot of opportunities here - we are going through times where much of the infrastructure is still being built, so while gopher would be late to the party, it doesn't mean it wouldn't be welcome...

Perhaps those in the list have other possible targets to aim for...

-rh

All that is to support On Monday, February 11, 2002, at 03:26 PM, 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. > > For example we could allow actual linking to http servers, just like you > can link to telnet, ftp, and other resources. > > Also, we could change around the ASK structure, some people were > talking/complaining about it earlier. > > 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! > > 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. > > Any other ideas? > > > >