[gopher] Re: Gopher wishlist
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?
>
>
>
>
Reply to: