>
> Whenever Caching of objects gets into the spec we'll probably
> need some sort of node to identify a new site, so that definitions
> don't overlap.
>
It seems to me that a scheme for caching objects is exactly the sort of
thing that you *don't* want in the VRML spec. My opinion is that object
caching is a feature of (or even the responsibility of) a "smart" transport
agent associated with the client browser or the server software. It's often
an *extremely* difficult call to decide between what is a part of the object
spec and what is a feature of the software that uses it. If you make the
wrong decision by adding it as a feature, it is irreversable and you are
stuck with that decision forever. However, if you make the wrong decision by
leaving it up to the client or server software, you can always reverse your
decision.
Object caching can be implemented in any number of ways ranging from some
sort of (.dll) library-file implementation to a complicated staged
replicator or by simply loading a file placed in a mass storage device such
as a CDRom. Object caching is something that would be benifitially to any
sort of client\server architecture. With this in mind, client software would
want a generalized protocol that works as well with HTML as it did with VRML
and, in fact, as it did with the retrieval of any sort of object. This
becomes especially apparent when you alter software to become multi-threaded
and/or work on "smart" servers.
As the world moves closer to models exploiting the ideas of "ubiquitous
data" (such as Mirror Worlds), *specific* designs for caching parts of an
object that are built *into* the object format (VRML being one such object
format) will become much less of a help and much more of a kludge. With
VRML, (or any immerging object format for that matter) I would like to see
non-generalized features omitted, even if it initially seems to limit the
functionality of the standard. Having worked on commercial languages and
frameworks in the past, I am painfully aware of design decisions that in
early versions were viewed as additional features (or even break throughs)
but end up in later versions as being "legacy code" to ruefully support.
> Say I go to one site with its own "chair" object and then I
> go to a new one with a new "chair" object... So how about
> a NewSite {} node..
Again, wouldn't the browser be able to determine this without having to add
an additional keyword to the specification?
Robert