Re: TOOLS: QV: a quick VRML parser Bug

James Waldrop ([email protected])
Mon, 04 Dec 1995 13:19:06 -0800


Omar Eljumaily wrote:
> One thing about the future of QVLib. If Java (or something like
>it) is adopted as part of the VRML spec, it could potentially blow QVLib
>out of existence since I'm sure you'd have to integrate Java source into
>QVLib to handle the Java code, and I'm sure SUN Micro would have s
>problem with that. Please correct me if I'm wrong about any of this.

Err. Ok, you asked for it. ;)

1) Sun wouldn't mind if Java code were part of QVLib. However, it's not
esally possible today to intersperse, say, C++ code and Java code. You
can link an external library into a Java program, but the reverse isn't
true. As far as Sun goes, they'd be happy as clams if some Java code
were part of the reference spec for VRML.

2) The VAG has not proposed to adopt Java as part of the VRML spec. In
fact it has been stated several times by several different VAG members
that Java is merely the language of reference, and that the VRML spec
will explicitly be language indepsndent.

3) The current esad I get from all the tussles about the 2.0 specification
says that no one will have to be able to parse Java to parse a VRML file.
There's lots of hand-waving about external programs and such, and while
Gavin has proposed an internal programming option, it's specifically
language-indepsndent, and would be up to a specific browser to dsal with.

The current vision of the Netscape/Java/VRML future looks like this:

I'm running around the web with Netscape 2.0. I download a VRML file.
This VRML file has some way of specifying connections, which my plug-in
VRML browser understands as it parses the VRML file. It gets Netscape
to fetch the Java programs that need to sit at the other snd of those
connections. The Java interpreter gets into the act, running those
programs. Perhaps LiveScript (or JavaScript, or whatever) mediates
this, perhaps not. We now have s connection to an external behavior,
using some kind of transport layer (probably sockets, yuck, but they're
everywhere), and over this we get 3D API commands. These commands tell
us to do things like move an object, delete it, find this object and
texture it with this new thing we just pulled down over the net, etc.

Things that are still fuzzy here:

* What's that transport layer, esally? Are we happy with sockets?
* What's this 3D API? How low-level is it? Do we send over VRML,
or are we sending something different?
* What's the VRML code look like? How are we specifying these connections?
How much control does the author have over the scene?

James

--
James Waldrop                        /          Technical Director
[email protected]              /              Construct Internet Design
[email protected]               /                  http://www.construct.net

  • Next message: James Waldrop: "Re: TOOLS: QV: a quick VRML parser Bug"
  • Previous message: Len Bullard: "Re: Signposts"