Date: Fri, 25 Mar 1994 12:14:19 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9403251714.AA05023@brainy.smarts.com>
To: timbl@www0.cern.ch, uri@bunyip.com, mpm@boombox.micro.umn.edu
Subject: Re: how to make progress on the URL document
> A caching scheme must have a way of fetching (and re-fetching) the resource.
> This implies that there is a client around that knows the details of
> the access method's protocol. In other words, you have a client that knows the
> protocol, but you need a "?" convention because you don't know the protocol...
I don't see any reason that the caching mechanism needs to be built in to the
protocol transport mechanism. In fact, good software design principles
suggest the opposite. The caching mechanism can be built completely separate
from the details of the protocol transport, and can simply pass URLs to the
specific URL retrieval engine for the URL protocol type whenever it needs to
get something that's not in the cache. This way we don't need to implement a
different caching mechanisms for each protocol transport.
This is fairly similar to the client design principles mentioned in Phill
Hallam-Baker's response (although he was addressing the similar issue of
reserving the / separator for hierarchical structure in URLs which are
hierarchical).
> In some ways this sounds like a cheesy way of trying to get time-to-live or
> cache timeout meta-information about the resource into the URLs.
The ? query separator serves two purposes; one is an indication to a user
interface client that there is a query embedded in the URL - a client may use
this information to make that query available for user inspection or possible
modification. The other is an indication to a caching mechanism that the URL
represents a query - a client or caching support program may use this
information to disable caching in the absence of URC information to the
contrary.
It's worth considering that although most documents will probably end up being
given URNs and having URC information maintained for them, it is unlikely that
this will happen for most query specifications, especially given the
combinatorial number of valid query specifications which can be constructed.
Much more likely is that most query specification URLs will exist in
isolation, without any supporting URC information. You may think it cheesy to
embed in the URL an indicator of whether or not it is a query, but given a URL
with no URC information available, I'll take cheesy any day.
> Given
> the general agreement that non-required-for-retrieval meta-information does
> not belong in URLs, this is a poor argument for requiring a "?" convention.
> Since partial/relative URLs aren't in the requirements document, arguments
> about how nice it would be to have this non-required feature don't carry much
> weight.
You're making an argument that since these features are not required, that
they aren't useful or worth weighing against other design considerations. I
haven't seen any mention of Gopher+ support in the requirements documents
either, but I certainly wouldn't argue that it isn't useful or important.
@alex