Keep an eye on Java...

Mark Waks ([email protected])
Tue, 25 Apr 95 11:32:35 EDT


Just a thought, and not to start any religious wars, but --

I've been hearing lots of vague talk here along the lines of,
"Wouldn't it be nice to have a public domain VRML browser?" It occurs
to me that, if Java lives up to its billing, it might well make a good
basis for that. (Note that this has *nothing* to do with the
using-Java-for-behaviour discussion; I'm talking here about the
possibility of using it to implement a browser.)

Consider the following rough design:

We would have a standard VRML parsing engine, and a base rendering
engine. These would be relatively stupid; their major purpose would
be to support the nodes, which would be added on top.

For each node, we would have a package, probably named the same as
the node. Each node package would define two separate parts:

1) A table of the fields and children acceptable for that node, which
the parsing engine would read. Plus (maybe) the definition of the
class corresponding to that node. (The latter would depend on how we
implemented this thing.)

2) A collection of methods for rendering that node from the scene graph.

The parse engine, given a VRML file, would go through the node list,
using the parse tables to build up the scene graph. If it hits a
node type that it doesn't know, it would attempt to get it from the
server, a la HotJava.

Then, once the graph is built, the rendering engine would traverse it
in the usual way. It would call the main Render method on each node
as it goes; those methods would do most of the work, calling on a
standard collection of interface routines for at least part of it.

(This glosses over what is probably the hardest problem: distributing
the rendering job like this. I'd bet that this would take some work;
however, I suspect it could be done if we tried. It also ignores a few
interesting issues, like how we would deal with Materials (which are a
bit different); again, I suspect we could cope, if we were careful in
designing the sucker. It also assumes that we can run fast enough in
Java. Sun claims that compiled Java code runs nearly as fast as native
C; if that's so, this should work.)

There are two real advantages to doing this in Java, closely related.
Java is designed, essentially, to maximize support for distributed
development -- that's the whole notion behind HotJava, really. It
means that once we've gotten the central engines done, we ought to
be able to farm out the actual nodes to those who want to implement
them. This might make it easier to develop something with a part-time
team of volunteers. (Fortunately, VRML is *very* well-suited to this
sort of thing, with lots of more-or-less disjoint nodes.)

The even bigger advantage is that it is *very* well-suited to
experimentation. We're entering a phase where rapid experimentation is
probably a Very Good Thing -- we really don't know *what* capabilities
we want for cyberspace, and we want to allow people to play easily.
Java is extraordinarily well-suited to this sort of thing, particularly
if you adopt a HotJava-like model for uploading new stuff. Experiments
would simply be new node packages, just like the built-in ones. We should
probably mandate that experimental nodes get prefixed with "x-" like
MIME does, to keep things from getting *too* chaotic, but other than
that we should probably let the proverbial thousand flowers bloom.

The key advantage here is that experimenters would be able to add just
a node, without needing a whole browser source. The HotJava setup is
designed well for this sort of ad hoc game-playing, and that's exactly
what we want. It would probably speed the development process a great
deal -- and it would be a *hell* of a lot of fun.

Think about it. We don't need to do this now -- indeed, doing
*anything* before Sun officially announces the terms on the Java
system would be highly premature. But if Sun makes Java available
on reasonably favorable terms, I'd say that this would be a *very*
sensible course for us to explore for that public-domain browser.

(For that matter, it would be a good course for a commercial one, too,
if anyone wanted to do the guts of the work themselves. I know that
*I* would look particularly favorably on a browser this flexible...)

-- Justin

Random Quote du Jour:

"We'd make a great couple -- we already can't stand each other. It
would save us about ten years of marriage."
-- -Steven Lee Pearson-