Re: Caching and Common Objects

Peter J. McCann ([email protected])
Mon, 29 May 1995 16:23:13 -0500 (BLT)

> I for one think everyone should stand back and take a look at the big
> picture before we pollute VRML with caching schemes. First, let's
> define the problems we want to solve:
>
> 1) World builders want the potential to specify an object in
> "real-world" terms. An object builder wants to say, "Put an
> elephant" at 0,0,0; insead of having to specify the exact methods
> to draw a specific elephant.
>
> 2) Browsers don't want to download huge models of elephants,
> especially if they have a perfectly good copy of an elephant in the
> local memory, hard disk, or CD-ROM drive.
>
> 3) Everyone wants to have some sort of centralized library of standard
> objects that could be easily replicated. Everyone wants a way to
> access a repository of information that might have a model of an
> elephant.

It has occurred to me that a lot of these problems could be addressed
by incorporating object-oriented style inheritance into the VRML spec,
something like the following:

FancyTeapot {
fields Teapot [ SFFloat fancyparameter ]
< .. list of attribute, value pairs .. >
}

Meaning, "an object of type FancyTeapot has all the attributes of a Teapot,
plus an SFFloat called fancyparameter."

Then the three requirements can be satisfied as follows:

1) World builders can say, "Put an object derived from elephant
at 0,0,0. I don't care what it actually is, but I need it to support
this basic interface." This also addresses the issue of a world
author's control over the space he has designed. The author can take
the semantics of his world into account when deciding how deep in the
inheritance tree he should go. If required, he could even derive a
completely new type. Browsers would have to satisfy this minimum
interface for the full effect of the scene, but would still have the
option of ignoring the extra attributes and using some base class of the
object the author specified.

2) Browsers have the option of substituting either a child or parent class
instead of the object specified. They could substitute a parent when
trying to conserve bandwidth, since parent classes are more common
and are more likely to be cached. In addition (and this is not a
part of the original requirement #2 above, but something that has
been discussed) they could substitute a child class when the user is
trying to customize a world. If I'm really proud of my FancyTeapot,
I could tell my browser to always substitute it whenever it sees a
Teapot.

3) A centralized library of common base classes could be maintained
as a cache in RAM, CD ROM, or third party network site. Definitions
for classes could be specified in terms of more complex scene graphs,
which might be supplied by the same or a different server; or as
platform-dependent rendering code, if the source is trusted.

-- 
Pete McCann                                          [email protected]
Department of Computer Science           http://swarm.wustl.edu/~mccap/
Washington University in St. Louis