Gopher+ and URLs (Erik Ostrom)
Date: Thu, 15 Apr 93 11:35:31 CDT
From: (Erik Ostrom)
Subject: Gopher+ and URLs
Message-id: <9304151635.AA01375@next-7>
(If there's a better forum for discussion of URLs, let me know.)

At the Gopher conference this Monday, a few people tried to convince
the UMN Gopher team to alter Gopher+ to use URLs.  (I wasn't one of
them, but I agreed.)  Having done a little hacking today on the
gopher-handling part of w3.el, though, I'm wondering about the
interaction of two facts:

>The path is interpreted in a manner dependent on the protocol being used.
>However, when it contains slashes, these must imply a hierarchical structure.
(from the URL spec)

but the Gopher protocol insists on the opacity of selector strings.
That is, if a Gopher selector string is "fumble/foo/.././bar/../baz", it
is *just that*, not "fumble/baz", which URL interpreters would come up

I think this could be gotten around by quoting slashes in the path
part of a URL, although I'm not quite sure where the unquoting takes
place, so this might not work.  However, this seems unnecessary to me.
I guess what I want to ask is, why is any URL that contains a slash
forced into a hierarchical interpretation?  I would prefer that
specific schemes (http, ftp, afs, prospero?) be classified as
hierarchical, and hierarchy-based translations be limited to those
schemes.  New schemes, as they appear, can specify whether or not they
follow the standard hierarchical-structure rules.

This implies, of course, that if a client isn't familiar with a given
scheme, of course, it can't know whether or not to perform
translations on URLs in that scheme.  I'm not convinced that this is a
bad thing--if a program doesn't understand an address, it can just
pass it off to another program (e.g., a gateway) that does.

So, what am I overlooking?  I realize this would require clients to
store an additional piece of information for each scheme (hierarchical
bit), but this doesn't seem like a great cost to me in exchange for
some opacity of paths.