> Andrew C. Esh writes:
> > On the other hand, applying the idea of "dynamic" to the data file which
> > is sent to the browser, then, yes, without further server updates, the
> > .wrl would have to be static, given that there were no other external
> > influences.
>
> I was under the impression that some of this terminology had already been
> decided upon in previous discussions.
Yes, as was I. However, I see the discussion continuing, and starting to
go in directions which I understand are not the most beneficial. So I
post. Maybe is we had a spec, we could tell those who are unaware to RTFM.
> 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.
Sure that's fine. I tend to speak more generally, and because I do so
doesn't mean I am setting limitations to implement only what I suggest.
> > The main reason I wanted to keep the animation code out of the current
> > spec, ... 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).
> 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.
^^^^^^^^^^^^^^
(I consider yours to be a rather cold reply, by the way.)
Let me explain. I started out using the word "dynamic" and had it pointed
out to me that a space can be "static" and still be animated. So now I
have you misunderstanding the word "animated". By animation, I mean
something in the space changes, either because the server siad it had to
change, or the next line in a file being read by the browser says that
something is being changed. I was using the word to define a .wrl that is
"changing", but not neccessarily because of some external inluence. In my
parlance, I was using "static" to refer to position. This means that all
the objects are not moving. Now, you tell me what word I should use,
which does not also imply that a server has to be used. Delta-ing?
Changing? What?
Also: Because I say "animation" does not imply that I expect the server
to render all the frames. Where did I say anything resembling that? My
whole point of view is to create something that can be used WITH OR
WITHOUT transportation, so if I want to read a "changing" .wrl file off a
CD-ROM, I can, and it loads, and it moves, and stuff changes while I view
it. The server may be useful, but it is not essential to the idea of
changing spaces. See Doom.
Maybe we should use the terms "live" and "dead". "Dead" means the space is
just the current VRML. A snapshot of a 3D space. It doesn't move at all.
"Live" means the space may move, change, or have objects appear and
disappear. Something as simple as a clock which has moving hands, getting
its time from the user's system clock, is all that is needed to make the
space "live". Not a server update, necessarily.
> > 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.
Uh, may I politely point out that you have misunderstood me?
> I might ask a server
> to add an object to my dataspace when a certain condition is true.
This is what I was trying to say by using the word "animation", or
"dynamic". Putting an object into a space is a "change". A space which
can have an object come into existence (for any reason) is "live".
> This
> object would appear in my browser and serve as notification. No animation,
> just a dynamic addition to my world.
Aha! But what if that "dynamic" change came from a "static" file of
movement commands? That is exactly what I would call "dynamic", but it
was pointed out to me that the sources are "static", so the space should be
referred to as "static". I started out using "dynamic". We're on the same
side, here.
> > 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.
Uh, now you are arguing on the same side as me. Which is it? Maybe this is
more misunderstanding about the word "animation". How about this: A
transport spec, and and update spec. Updates can come from a source that
does not require transportation (a file, or a pipe from your network
packet counter). Transportation can be used for things other than updates,
such a simple file transfer (as HTTP now does).
> > For a demonstration of a "continuously updating" Web page, see:
> >
> > http://www1.netscape.com/fishcam/fish_refresh.html
> >
> > 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.
OK, now I'm beginning to think we are talking about the same thing.
> I just wanted to suggest CORBA
If there is a better way, I can be convinced. I knwo what I think we
need. How it gets done is not a big problem for me.
> I might go ahead and write one if I get the time...
Please do. Then we would have something solid to talk about.
> 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.
Aha! I thought there may be something we still need to do there.
> 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?
Yes, we can leverage off from anything that the rest of the Web is doing
to solve this problem. It's not unique to what we are trying to do. Maybe
the URN effort?
---
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>