Re: Client-side expanded url's

> From owner-uri@bunyip.com  Thu Mar  7 06:09:12 1996
> From: Mirsad Todorovac <tm@rasips2.rasip.etf.hr>
> Subject: Client-side expanded url's
> To: uri@bunyip.com
> Date: Thu, 7 Mar 1996 09:59:35 +0100 (MET)
> Cc: tm@rasips2.rasip.etf.hr (Mirsad Todorovac)
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> 
> There are situations, especially in documents related to Internet and
> some other areas, when you can fetch desired document from multiple sources.
> The locations may differ in "net length" between client and paticular servers,
> and servers may differ by their average load.

Another dimension that could be considered here is versioning of documents.
In the case of language negotiated documents the documents could be 
distributed geographically.

> 
> Therefore it would be of practical value to have such URL's where part of
> the URL would be expanded on client, by some brosers setting or environment
> variable.
> 
> Then URL would break into two parts:
> 
> 	- client modifiable part with default value
> 	- database specific part
> 
> Eg. when we reference RFC1738, we could do it like this:
> 
> 	http://{$RFC_DEP|ds.internic.net:/rfc/}rfc1738.txt
> 
> [ Now, please ignore the syntax, because it is not a part of proposal, just
> a way to express desired subject. ]

I agree that some sort of client side mechanism would be useful here, but 
I have a hard time understanding it in terms of a client side variable.
This requires coordination between a document author and an end user
setable parameter.

If we look at the same problem as a caching  (or replicated object repository),
problem then we can eliminate the need to coordinate with the authoring of the
URL. In other words the user still has the flexibility to parameterize the
path to the information and the local user agent and proxy system collaborate
to deliver the document in the most efficient way.

> 
> This would mean:
> 
> 	Get rfc1738.txt from ds.internic.net, directory /rfc/
> 
> 	or from your preffered site, specified in environment variable
> 	WWW_RFC_DEP, which you can set to your nearest mirror.
> 
> This proposal, in contrast to URI's, requires only minor changes to
> clients, and it should be considered how to deploy it into current URL
> scheme, and whether it is posible to do it without breaking existing
> browsers (which in that case couldn't get object even from distant, slow
> site).
> 

I can imagine a network of caches that an end user might want to use at 
a work group, site location or organization wide repository to improve
latency and overall bandwidth utilization. A caching approach would 
not require any modification to URL syntax and provide the same benefits
as the client side parameterization you have proposed.
> 
> 
> -- 
>     | Mirsad Todorovac					|
>     | Faculty of Electrical Engineering and Computing	|
>     | University of Zagreb				|
>     | Unska 3, Zagreb, Croatia 10000			|
>     |							|
>     | e-mail: mirsad.todorovac@fer.hr			|
> 
>

Received on Thursday, 7 March 1996 08:05:15 UTC