Re: how should remote path names be handled?

Christopher McRae (mcrae@lib.ucsf.edu)
Fri, 23 Apr 93 16:38:47 MDT


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
expand.
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
http://$least_busy_of_group_GROUP/foo.html.
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