> >Am I right in thinking that you can specify a "file" URL in a document that
> >is not itself a "file"? IOW could http://www.mystuff.com/home.wrl include
> >a WWWAnchor with the URL "file:///c:/vrml/objlib/chair.wrl"?
>
> Yes (or at least, you *should* be able to), and yes, I think your plan
> would work. I think it's a bit impractical in the long run, though. If
> nothing else, I have *no* desire to *require* people to have a CD of
> standard objects (I think that's unlikely to fly) -- rather, it would
> be nice to have a mechanism flexible enough so that if the user *has*
> such a thing, it can boost their performance.
Yes, I agree. A lot has been posted on this recently. In my opinion, one
of the problems we could be faced with is an object in a .wrl which used
to be on a remote site, but is now locally cached on a CD or hard disk.
We don't want to change the .wrl file every time we decide to cache an
object. If we had an external (to the browser) database that decides what
the actual URL is for each object being referred to (be it local or an
alternate remote site), then we could have libraries of objects, each
with a URL to find it.
What this really gets down to, though, is a cache system that is more
complex than most Web browsers use. It does not need to be part of the
VRML spec. The cache only needs a method for keeping objects current
based on criteria like whether the CD is mounted, or the number of hits
we get on the object (as opposed to how recently we loaded it). You don't
even need to provide a method for feeding CD object into your cache: Just
expect that tyhe CD will have a .wrl file on it that refers to all the
objects on the CD in one shot (or many categorized shots), using a
"file:" reference. Those don't get cached as whole files, just as
references. Load the .wrl file that is a warehouse full of tea pots, and
your browser then knows where to go to get any tea pot it ever needs.
The problem now is: How does a remotely defined .wrl file refer to a tea
pot in such a way as to make sure you load "TeaPot3527.wrl", which is a
specific short, round teapot? (Notice I left out color and texture.) The
name would have to be registered somewhere to make sure no one else
defines a tall, octagonal one with the same name.
My answer is: We don't need any of this. The bandwidth problems will be
solved by simple caching, and improvements in line speed. Currently,
there is no such concept as a common object in HTML. There are ones that
people use a lot, but they download them and put them in and with their
pages. Each client loads them, even if the same object was just loaded
from another site. Common object decisions are really made and maintained
at the server, by putting icons and .GIF files in a common directory. Why
does VRML need anything different? I don't how we can solve this without
resorting to some sort of "domain object system", which allows unresolved
local object references to be satisfied by remote servers who cache the
objects. All objects would have to belong to a registered domain, and
have a registered name.
I see all this as workable, but complex enough not to warrant further
discussion. If some other systems begin to make use of a common object
caching system (DNS, Yellow Pages, HTTP, NFS), then let's jump on the
bandwagon, but until then, let's not pull it. ;)
(And now for something completely different ...)
On second thought, since VRML is on the top of the heap, both in terms of
bandwidth demand, and current Internet popularity, maybe we should be
pushing this. If we begin to solve it here, and get other interested
parties involved, maybe we will create an Internet-wide caching convention
which can be used to cause objects to migrate toward faster and closer
systems. Why transport the same objects thousands of times over the same
piece of wire, when a small portion of the value of the bandwidth being
consumed could buy a local object server that replies instead? Levels of
cache use would indicate the need for faster links or bigger servers. A
market would be created for local cache servers, married to the local
connection provider. The combination of those two will yield your
effective throughput on the net, and it drives the market for service.
Maybe MCI would be interested in setting up a bunch of disk arrays in
major markets, all serving out generic objects to all sorts of local
systems. Think about it.
---
Andrew C. Esh mailto:[email protected]
Computer Network Technology [email protected] (finger for PGP key)
6500 Wedgwood Road 612.550.8000 (main)
Maple Grove MN 55311 612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>