I was under the impression that some of this terminology had already been
decided upon in previous discussions.
To be completely general, I would expand the definition of "dynamic" to
include any change in the scene graph that would require IPC, not just
browser/server communication.
> > However, I
> > disagree with your statement that the encoded-in-the-scene behaviors
> > should not be part of the spec.
>
> I would love to put them in the spec. Maybe in a later version. We want
> at least the statis-non-animated (current) VRML spec to get out and
> become popular, though. It's useful, as it is. In later spec versions, we
> can add the animation code, if we want to. Since it's a separate problem,
> though, it can be a separate spec. We can't lump everything into one spec.
I agree. None of what we are talking about here belongs in the 1.0 spec.
> > I think they belong in the spec even
> > more than the dynamic update features. You seem to be saying that it
> > is so easy to specify such static behavior that the spec shouldn't
> > even bother with it. I say it's a very logical extension that can
> > and should be put into the next version of the spec. Dynamic transport
> > of objects is much farther in the future.
>
> The main reason I wanted to keep the animation code out of the current
> spec, (aside from wanting the current spec to get finished sooner), is
> because I feel that the way the animation is going to be used most often
> (server updates to client spaces) is going to cause the way the animation
> code works to be driven, somewhat, by the way the updates are delivered.
> This implies a connection between animation and transportation (but not a
> requirement that they be the same spec). For this reason, I think the
> current spec should be left alone, and allowed to become an atom we can
> work with. The animation spec would be developed, along with (but not
> lumped in with) the transportation spec. The way the transportation spec
> develops will determine how the animation spec will refer to objects. The
> way animation frames (possibly time-based) need to be transported to the
> client will determine how the transportation spec needs to work.
No, I disagree completely. The issues of animation and transportation
are orthogonal. If transport is the way animation is handled, that
means my server is sending updates on a frame-by-frame basis. The
server becomes a centralized bottleneck to the performance (realtime
frame rate) of everyone's browser. I think there are some very
interesting uses for dynamic updates, but animation is not one of
them. Until ATM switches become ubiquitous, there are simply not
enough real-time guarantees (both latency and jitter guarantees) on the
Internet to allow animation to be treated as a transport problem. I
think it is unreasonable to say that most animation will be implemented
as server updates to client spaces.
> If the animation spec is kept separate from transportation, then it also
> becomes an atom we can use. The VRML atom and the animation atom, in
> combination, can be used to build a stand alone animated space. The home
> .wrl with a load average gauge on the wall is an example of this. Add
> transportation, and you have the whole pie. Note: Transportation would
> never be needed without Animation (we can use HTTP, to move VRML-only
> .wrl files), but the reverse is not true. You can also use HTTP to move
No, this is wrong. I can envision quite a few ways to use Transportation
(which I assume means you are talking about dynamic, incremental updates
to the scene graph) without scene-encoded animation. I might ask a server
to add an object to my dataspace when a certain condition is true. This
object would appear in my browser and serve as notification. No animation,
just a dynamic addition to my world.
> VRML-Anim .wrl files that do not need a dynamic connection to the server.
> These would be like movies. When you need the dynamic updates, then HTTP
> falls apart, and we need our more robust Transportation atom.
>
> Most of what is needed for animation is probably already in the VRML spec.
> We can simply redefine an object in order to move it.
Once again, I don't think this will scale well at all, either to large
numbers of objects or high frame rates. I think both an animation spec
and a transport spec are needed.
> New objects can be
> added with pieces of VRML code. I feel there is a border area where named
> objects will be used between hosts to refer to objects being changed.
> Some work will have to be done to make sure we can do animation with
> that. The transportation spec needs the most work, in my estimation. HTTP
> can be used for the low level part, but we would need to add the same
> sort of extensions to it that Netscape did to do their dynamic updates.
> For a demonstration of a "continuously updating" Web page, see:
>
> http://www1.netscape.com/fishcam/fish_refresh.html
>
> It uses Server Push, and Client Pull to keep a .GIF image animated
> (slowly, but surely). There is a link near the bottom of that page which
> takes you to an explanation of how this is done.
>
> If we can add Push-Pull to HTTP, make it move pieces of VRML code
> containing named objects, and build a browser which can accept a
> connection, grab the VRML pieces, and apply them to the space, we'll have
> dynamic spaces.
This might be a very good way to go about it, and it fits in well with
existing browser/server technology. I know very little about how the
Push/Pull protocol is implemented, but I just wanted to suggest CORBA
as a possible alternative that might produce a cleaner, easier to use
API. I think a CORBA IDL could be written pretty easily that would
take most of the transport issues into account. There should be methods
for adding, deleting, and replacing nodes, and perhaps replacing field
values. I might go ahead and write one if I get the time...
One problem that has been touched on in previous posts: unique identifiers
for objects that get manipulated in this way. Someone (I think Chris)
suggested that the DEF mechanism is sufficient for naming objects. This
name is only unique to a .wrl, however. It might not prove sufficient if
browsers start to create their own worlds from composite scenes supplied
by several servers. What we would need then, to avoid namespace collision,
would be some sort of unique ID for each object based (probably) on the IP
address and process id of the server it came from, along with a server-specific
index for the object. I think there are people (maybe at cern, I don't
remember) working on a generic unique identifier system for the web. Does
anyone know more?
-pete
-- Pete McCann [email protected] Department of Computer Science http://swarm.wustl.edu/~mccap/ Washington University in St. Louis