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
with.
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.