Re: how should remote path names be handled?

Christopher McRae <>
Message-id: <9304232337.AA21197@knowman.lib.ucsf.EDU>
Subject: Re:  how should remote path names be handled?
Date: Fri, 23 Apr 93 16:38:47 MDT
From: Christopher McRae <>

Jay C. Weber writes:
> How about variable name substitution in URLs?  E.g., you
> could use a HREF=file://$parentsite$parentdir/foo.html to make
> explicit how the broswer should construct relative pathnames.
> The advantage of this over the current HREF=file:foo.html
> scheme is it opens up many other kinds of context-sensitive
> URLs, like substituting the parentsite but naming a new
> directory path.  Or, browsers (the WWW library I guess) could
> define new variables like $standardsite, which would depend
> on the user's continent (per the recent suggestion about
> distributing servers).

  If you are going to add variable substitution to URL's, then perhaps
it would be best to define two types of variables: those which are
to be interpreted by the client, and those which the server should
  Thus, a user could configure their browser session so as to
force a particular interpretation of any "variant" links
encountered.  The $standardsite variable mentioned above is
one example of a variable which should be interpreted locally,
i.e. by the client.
  Server-interpreted variables, on the other hand, could be used
by information administrators to ease the task of maintaining
document archives and to enhance reliability and efficiency.  The
$parentsite and $parentdir variables mentioned in Jay's message
are examples of these types of variables.  Another example would
be a $least_busy_server_of_group_GROUP variable, as in
The server would replace this variable with the address of the least
busy server in the group of servers named GROUP.
  So, how are the two types distinguished?  Suppose that a server
variable is preceeded by a single '$'. and client variables would be
referenced by two $, o