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>
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


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