> From: "Gavin Bell" <gavin@krypton.engr.sgi.com>
> Date: Wed, 2 Nov 1994 11:05:55 -0800
> Subject: Re: Dictionaries, scoping
>
> > > Which shouldn't be too hard to implement; it would look like:
> > >
> > > Define {
> > > name "BorderColor" # SFString
> > > value Material { .... } # SFNode
> > > }
I forgot to ask, what about re-definition semantics?
If I say
Define {
name "BorderColor"
value Material {...}
}
later on, does it redefine BorderColor, or append to it?
If it redefines, then there is some hope of using it as
an "editing" operator for the VRML MUD's. This is somewhat
deep water, as again, I'm not sure what you folks have operational,
but ... consider the following:
When I first enter a VRML room, the server sends me the room
description, which contains a Define { name "BorderColor" Material
{ ... # Some green brass oxide color}. My VRML browser draws
a room with a green vase in it. Later, the server sends out
Define {name "BorderColor" Material {...} #Some Gold color }
The correct operation for my browser is to replace it's current
definition of BorderColor, and redraw the scene. Right?
> > You seem to hint that the Separator should do the scoping,
> > but I'm a little concerned with overloading the Separator
> > with too many features/functions. It already does a lot of
> > things, giving it one more responsiblity may in the long run
> > divert it from it's original intent -- to act as a
> > "collection class" to contain child geometry & material.
>
> Maybe. But I think Inventor users already think of Separators as the
> general scoping operators; after all, they scope the effects of all
> property nodes.
Well, yeah, but ... OK.
I just wrote and erased a long thesis. I was concerned about
performance. I'm using a system that's quite different than
Inventor, and one of the big differences is how the Separator
(called a "Composite") works. It's very fast; it derives a
lot of that speed by avoiding un-needed pushes & pops. (Do
note, in real life, pushes & pops other than material &
transform, are rare). I was going to brag to you about how
I can whip through a Composite at about (cost of C++ virtual
method call + 10 cycles per child), but what the heck. Thats
not the point.
Yeah, the Separator can be used for scoping, and if the file
reader wants to do something special when handling dictionaries
so as to avoid un-needed work, it can.
I was going to say something about "let the user give you a hint
as to when to push/pop dictionaries", since it is unlikely that
there will be a lot of dictionary pushing/popping.
> If there is only one dictionary, then it can be though of as just
> another property. Instead of a current material, there is just "the
> current set of definitions".
This is one of my philosophical disagreements with Inventor ...
it is wrong to think of things as "just another property". But
we'll save that for a rainy day.
> > Maybe the "dictionary" could provide that scoping?
>
> You could certainly implement that (and when I say "you" I really do
> mean YOU-- Inventor is meant to be extended).
Hmmm. Although its good to provide the tools for easy extensibility,
I'd also discourage rampant extensions to VRML. Could make for an
interoperability nightmare -- all of a sudden, you'd need another
standards body to standardize the standard extensions. Just take
a look at NI-1, or SNMP, or, heck - PHIGS.
Better to do it all, and do it right, the first time.
> > Assume that there will be lots of definitions.
>
> Are you envisioning huge libraries of materials, textures, etc?
I'm envisioning large, complicated VRML spaces.
> I don't see that happening-- if you Define 1,000 objects that means all
> 1,000 objects have to be read from disk and stored in memory. Unless
> you add a lazy-load feature and some kind of search-path to Use... at
> which point my complexity aesthetic kicks in and starts exploring
> other, simpler solutions (e.g. the PartFromFile { filename "stuff.iv"
> part RedMaterial } node).
Well, I don't understand this at all.
1) I would assume that how the defines are handled are an implementation
detail. If you folks want to do it one way, great. If we license your
code, we pay for your sins. Or we do it our own way. Whatever.
2) I suddenly realize that the "partFromFile" idea is very UNIX-centric,
and stems from the lack of support for "persistant objects" in UNIX.
(and in DOS, and Windows, and NT, ans OS/2). However, some operating
systems don't have "files". Instead, they have "persistant objects"--
they are in memory when you need them, they are on disk when the power
is turned off. They are in a tape archive when someone hasn't touched
them for six months. The programmer doesn't really know, or care,
about where they are, or what they're doing, in the same way that we don't
care whether something is in a register, in the first-level cache, the
second-level cache, whatever. It's automagic. Parts of NeXT worked
something like that, and I am told that's how IBM's OS/400 works.
(On the OS/400, they may not even be on the machine you think it's on,
but maybe even some remote site -- "persistant distributed objects".)
So, I'll say -- get rid of those silly little files.
--linas