On the one hand, I concur *strongly* with Thomas that we *must* do as
much as possible client-side. One fact of life on the Net is that
client processor time is cheap, and server processor time is pretty
dear. A number of Web sites are already breaking down because they're
overloaded (using GNN is no fun at all these days) -- VRML is going
to exacerbate that to begin with. The last thing we need is to burden
servers with dynamic processing; I'm pretty confident that such a
model will start to break down quite badly at about the time that
it starts to catch on. We might have the capability of doing *some*
server-side processing, but we *must* keep it low-key and de-emphasized.
Also, I'm afraid that I have to disagree with Mike about the
object-binding vs. language issue. If we're going to distribute the
dynamic behaviour to the clients, that means we have to send that
behaviour to those clients somehow. And *that* means we need to be
able to assume that those clients can interpret that behaviour. And
*that* means we need to have some sort of standard language, I
think. We should definitely have hooks in the language, so that more
sophisticated client-specific programs can be tied into it when
they're available. But I think we will need a standard language for
most of the simple work.
This argues for some sort of dynamic language specification for the
client to interpret. This means something *very* fast and easy to
interpret, which to me means either a dialect of Lisp or Forth.
Now, that said, I don't much like Meme, for two reasons. First of all,
it intermixes the static and dynamic more than I think wise. There's
a real benefit to clarity in keeping the static and dynamic properties
of a scene *somewhat* separately defined -- it makes the scene's code
*much* easier to understand, IMO. Second, it's a dialect of Forth
(well, it's *some* kind of TIL, anyway), and I really believe that
that's a lose. Postfix notation tends to tie peoples' heads in knots;
they're just not used to it. I have a soft spot for Forth (I wrote my
own dialect about ten years ago just for kicks), but I really think
it's going to hinder acceptance of the language. A simple dialect of
Lisp is likely to be easier for most people to understand, and just as
fast if it's written carefully.
Which translates to: I like Geomview's model of the world. It
clearly separates the static from the dynamic, while still
providing a fairly rich dynamic model to work with. Easy enough
to design for, and quite useable. (Although I think that Geomview's
language may be a little *too* simplified -- I suspect that, in
the long run, we're going to want something a little more robust.)
Now *that* said, I still don't much like OOGL as a language. Having
studied all of the proposals so far, I'm about 75% confident that
Inventor is the best proposal. I'll outline my reasons later (when
the Home Page is done getting restructured), but suffice it to say
for now that I like the language significantly the best. Now Inventor
*does* have roughly the same view of the world as Geomview, but
unfortunately the language it is intended for is C++. It's *quite*
clear to me that any dialect of C would be a mistake -- it's simply
too much work to parse. So I'm not really in favor of picking up
Inventor completely wholesale.
So -- my strawman view of things. We should take Inventor's ASCII
format as the base language. Our first cut should model just the
static behaviour; that is, it should just implement that ASCII
format (plus a few additions to make the distributed aspect work;
I've got this designed in my head already). Once that's working,
we should add the dynamic language, which would be primarily an
object-manipulation language. It would be a dialect of Lisp, and
focus on manipulating the scene database in various ways. It would
have hooks for connecting to outside programs, but would be capable
of a fair bit without those hooks. It should be as extensible as
possible, so we don't get trapped as the language evolves. (We
might even consider distributing the dynamic behaviours just as
we do the static; this is a *fascinating* idea, but we're not ready
for it quite yet.)
So -- whaddaya think?
-- Justin
Random Quote du Jour:
"Usenet is a system whose organization can only be studied using chaos
theory and catastrophe theory."
-- spaf